<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "https://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/xhtml;charset=UTF-8"/>
<meta http-equiv="X-UA-Compatible" content="IE=11"/>
<meta name="generator" content="Doxygen 1.9.4"/>
<meta name="viewport" content="width=device-width, initial-scale=1"/>
<title>Flow: common.hpp Source File</title>
<link href="tabs.css" rel="stylesheet" type="text/css"/>
<script type="text/javascript" src="jquery.js"></script>
<script type="text/javascript" src="dynsections.js"></script>
<link href="search/search.css" rel="stylesheet" type="text/css"/>
<script type="text/javascript" src="search/searchdata.js"></script>
<script type="text/javascript" src="search/search.js"></script>
<link href="doxygen.css" rel="stylesheet" type="text/css" />
</head>
<body>
<div id="top"><!-- do not remove this div, it is closed by doxygen! -->
<div id="titlearea">
<table cellspacing="0" cellpadding="0">
 <tbody>
 <tr id="projectrow">
  <td id="projectalign">
   <div id="projectname">Flow<span id="projectnumber">&#160;2.0.0</span>
   </div>
   <div id="projectbrief">Flow project: Full implementation reference.</div>
  </td>
 </tr>
 </tbody>
</table>
</div>
<!-- end header part -->
<!-- Generated by Doxygen 1.9.4 -->
<script type="text/javascript">
/* @license magnet:?xt=urn:btih:d3d9a9a6595521f9666a5e94cc830dab83b65699&amp;dn=expat.txt MIT */
var searchBox = new SearchBox("searchBox", "search",'Search','.html');
/* @license-end */
</script>
<script type="text/javascript" src="menudata.js"></script>
<script type="text/javascript" src="menu.js"></script>
<script type="text/javascript">
/* @license magnet:?xt=urn:btih:d3d9a9a6595521f9666a5e94cc830dab83b65699&amp;dn=expat.txt MIT */
$(function() {
  initMenu('',true,false,'search.php','Search');
  $(document).ready(function() { init_search(); });
});
/* @license-end */
</script>
<div id="main-nav"></div>
</div><!-- top -->
<!-- window showing the filter options -->
<div id="MSearchSelectWindow"
     onmouseover="return searchBox.OnSearchSelectShow()"
     onmouseout="return searchBox.OnSearchSelectHide()"
     onkeydown="return searchBox.OnSearchSelectKey(event)">
</div>

<!-- iframe showing the search results (closed by default) -->
<div id="MSearchResultsWindow">
<iframe src="javascript:void(0)" frameborder="0" 
        name="MSearchResults" id="MSearchResults">
</iframe>
</div>

<div class="header">
  <div class="headertitle"><div class="title">common.hpp</div></div>
</div><!--header-->
<div class="contents">
<a href="common_8hpp.html">Go to the documentation of this file.</a><div class="fragment"><div class="line"><a id="l00001" name="l00001"></a><span class="lineno">    1</span><span class="comment">/* Flow</span></div>
<div class="line"><a id="l00002" name="l00002"></a><span class="lineno">    2</span><span class="comment"> * Copyright 2023 Akamai Technologies, Inc.</span></div>
<div class="line"><a id="l00003" name="l00003"></a><span class="lineno">    3</span><span class="comment"> *</span></div>
<div class="line"><a id="l00004" name="l00004"></a><span class="lineno">    4</span><span class="comment"> * Licensed under the Apache License, Version 2.0 (the</span></div>
<div class="line"><a id="l00005" name="l00005"></a><span class="lineno">    5</span><span class="comment"> * &quot;License&quot;); you may not use this file except in</span></div>
<div class="line"><a id="l00006" name="l00006"></a><span class="lineno">    6</span><span class="comment"> * compliance with the License.  You may obtain a copy</span></div>
<div class="line"><a id="l00007" name="l00007"></a><span class="lineno">    7</span><span class="comment"> * of the License at</span></div>
<div class="line"><a id="l00008" name="l00008"></a><span class="lineno">    8</span><span class="comment"> *</span></div>
<div class="line"><a id="l00009" name="l00009"></a><span class="lineno">    9</span><span class="comment"> *   https://www.apache.org/licenses/LICENSE-2.0</span></div>
<div class="line"><a id="l00010" name="l00010"></a><span class="lineno">   10</span><span class="comment"> *</span></div>
<div class="line"><a id="l00011" name="l00011"></a><span class="lineno">   11</span><span class="comment"> * Unless required by applicable law or agreed to in</span></div>
<div class="line"><a id="l00012" name="l00012"></a><span class="lineno">   12</span><span class="comment"> * writing, software distributed under the License is</span></div>
<div class="line"><a id="l00013" name="l00013"></a><span class="lineno">   13</span><span class="comment"> * distributed on an &quot;AS IS&quot; BASIS, WITHOUT WARRANTIES OR</span></div>
<div class="line"><a id="l00014" name="l00014"></a><span class="lineno">   14</span><span class="comment"> * CONDITIONS OF ANY KIND, either express or implied.</span></div>
<div class="line"><a id="l00015" name="l00015"></a><span class="lineno">   15</span><span class="comment"> * See the License for the specific language governing</span></div>
<div class="line"><a id="l00016" name="l00016"></a><span class="lineno">   16</span><span class="comment"> * permissions and limitations under the License. */</span></div>
<div class="line"><a id="l00017" name="l00017"></a><span class="lineno">   17</span><span class="comment"></span> </div>
<div class="line"><a id="l00018" name="l00018"></a><span class="lineno">   18</span><span class="comment">/// @file</span></div>
<div class="line"><a id="l00019" name="l00019"></a><span class="lineno">   19</span><span class="comment"></span><span class="preprocessor">#pragma once</span></div>
<div class="line"><a id="l00020" name="l00020"></a><span class="lineno">   20</span> </div>
<div class="line"><a id="l00021" name="l00021"></a><span class="lineno">   21</span><span class="preprocessor">#include &quot;<a class="code" href="detail_2common_8hpp.html">flow/detail/common.hpp</a>&quot;</span></div>
<div class="line"><a id="l00022" name="l00022"></a><span class="lineno">   22</span><span class="comment">/* These are just so commonly used, that I (ygoldfel) decided to just shove them here for everyone because of the</span></div>
<div class="line"><a id="l00023" name="l00023"></a><span class="lineno">   23</span><span class="comment"> * following boost.chrono I/O thing being nearby anyway. */</span></div>
<div class="line"><a id="l00024" name="l00024"></a><span class="lineno">   24</span><span class="preprocessor">#include &lt;boost/chrono/chrono.hpp&gt;</span></div>
<div class="line"><a id="l00025" name="l00025"></a><span class="lineno">   25</span><span class="preprocessor">#include &lt;boost/chrono/ceil.hpp&gt;</span></div>
<div class="line"><a id="l00026" name="l00026"></a><span class="lineno">   26</span><span class="preprocessor">#include &lt;boost/chrono/round.hpp&gt;</span></div>
<div class="line"><a id="l00027" name="l00027"></a><span class="lineno">   27</span><span class="comment">/* boost.chrono I/O: This is subtle.  chrono.hpp doesn&#39;t include I/O (including the invaluable ostream&lt;&lt; output of</span></div>
<div class="line"><a id="l00028" name="l00028"></a><span class="lineno">   28</span><span class="comment"> * chrono::duration and chrono::time_point, especially when the latter is from chrono::system_clock).  (Probably that</span></div>
<div class="line"><a id="l00029" name="l00029"></a><span class="lineno">   29</span><span class="comment"> * is because std::chrono I/O support is spotty-to-non-existent, including lacking solid ostream&lt;&lt;.)  One must include</span></div>
<div class="line"><a id="l00030" name="l00030"></a><span class="lineno">   30</span><span class="comment"> * chrono/chrono_io.hpp... except, as it stands, this loads v1 -- not v2.  (Looking inside the header shows it&#39;s based</span></div>
<div class="line"><a id="l00031" name="l00031"></a><span class="lineno">   31</span><span class="comment"> * on some BOOST_ #define jungle, but the bottom line is every time I (ygoldfel) see Boost built, it loads v1, not v2.)</span></div>
<div class="line"><a id="l00032" name="l00032"></a><span class="lineno">   32</span><span class="comment"> * However loading v2 is easy (and correct): #include the following 2 files instead; chrono_io.hpp would do so itself if</span></div>
<div class="line"><a id="l00033" name="l00033"></a><span class="lineno">   33</span><span class="comment"> * the BOOST_ #define were set accordingly.</span></div>
<div class="line"><a id="l00034" name="l00034"></a><span class="lineno">   34</span><span class="comment"> *</span></div>
<div class="line"><a id="l00035" name="l00035"></a><span class="lineno">   35</span><span class="comment"> * This should be transparent, and transparently a good thing, for all `#include`ing devs.  There are some subtleties</span></div>
<div class="line"><a id="l00036" name="l00036"></a><span class="lineno">   36</span><span class="comment"> * however.  In particular these bear mentioning:</span></div>
<div class="line"><a id="l00037" name="l00037"></a><span class="lineno">   37</span><span class="comment"> *   - Output of a time_point from system_clock (e.g., chrono::system_clock::now()) to an ostream will (in v2) yield a</span></div>
<div class="line"><a id="l00038" name="l00038"></a><span class="lineno">   38</span><span class="comment"> *     nice, predictably formatted, human-readable date/time string that includes the UTC +0000 specifier.</span></div>
<div class="line"><a id="l00039" name="l00039"></a><span class="lineno">   39</span><span class="comment"> *     (v1 said something fairly useless -- which v2 still, by necessity, does for non-system_clock values -- like</span></div>
<div class="line"><a id="l00040" name="l00040"></a><span class="lineno">   40</span><span class="comment"> *     &quot;28374928742987 nanoseconds since Jan 1, 1970&quot;.)  This is used directly by flow::log for example.</span></div>
<div class="line"><a id="l00041" name="l00041"></a><span class="lineno">   41</span><span class="comment"> *     With chrono::time_fmt(chrono::timezone::local) formatter applied to the ostream&lt;&lt;, it&#39;ll be in local time</span></div>
<div class="line"><a id="l00042" name="l00042"></a><span class="lineno">   42</span><span class="comment"> *     with the appropriate +xxxx specifier, instead.  (There is also custom formatting available but never mind.)</span></div>
<div class="line"><a id="l00043" name="l00043"></a><span class="lineno">   43</span><span class="comment"> *   - Breaking change: `chrono::duration_{short|long}` don&#39;t work (v1); use chrono::{symbol|name}_format instead (v2).</span></div>
<div class="line"><a id="l00044" name="l00044"></a><span class="lineno">   44</span><span class="comment"> *     (This switches between, e.g., &quot;5 ns&quot; and &quot;5 nanoseconds.&quot;)</span></div>
<div class="line"><a id="l00045" name="l00045"></a><span class="lineno">   45</span><span class="comment"> *   - As of Boost 1.76 at least, v2 includes some deprecated Boost headers which results in a #pragma message (not</span></div>
<div class="line"><a id="l00046" name="l00046"></a><span class="lineno">   46</span><span class="comment"> *     a warning/error but verbose and unsightly).  -DBOOST_ALLOW_DEPRECATED_HEADERS will make it go away.</span></div>
<div class="line"><a id="l00047" name="l00047"></a><span class="lineno">   47</span><span class="comment"> *   - v1 and v2 cannot co-exist (some things, like ostream&lt;&lt;, become defined 2x).  Therefore do not attempt to</span></div>
<div class="line"><a id="l00048" name="l00048"></a><span class="lineno">   48</span><span class="comment"> *     #include &lt;boost/chrono/chrono_io.hpp&gt;.  At best it&#39;s redundant; at worst it will fail to compile. */</span></div>
<div class="line"><a id="l00049" name="l00049"></a><span class="lineno">   49</span><span class="preprocessor">#include &lt;boost/chrono/io/duration_io.hpp&gt;</span></div>
<div class="line"><a id="l00050" name="l00050"></a><span class="lineno">   50</span><span class="preprocessor">#include &lt;boost/chrono/io/time_point_io.hpp&gt;</span></div>
<div class="line"><a id="l00051" name="l00051"></a><span class="lineno">   51</span><span class="preprocessor">#include &lt;functional&gt;</span></div>
<div class="line"><a id="l00052" name="l00052"></a><span class="lineno">   52</span><span class="comment">// For certains compile-time checks below.</span></div>
<div class="line"><a id="l00053" name="l00053"></a><span class="lineno">   53</span><span class="preprocessor">#ifdef __APPLE__</span></div>
<div class="line"><a id="l00054" name="l00054"></a><span class="lineno">   54</span><span class="preprocessor">#  include &lt;TargetConditionals.h&gt;</span></div>
<div class="line"><a id="l00055" name="l00055"></a><span class="lineno">   55</span><span class="preprocessor">#endif</span></div>
<div class="line"><a id="l00056" name="l00056"></a><span class="lineno">   56</span><span class="comment"></span> </div>
<div class="line"><a id="l00057" name="l00057"></a><span class="lineno">   57</span><span class="comment">/**</span></div>
<div class="line"><a id="l00058" name="l00058"></a><span class="lineno">   58</span><span class="comment"> * @mainpage</span></div>
<div class="line"><a id="l00059" name="l00059"></a><span class="lineno">   59</span><span class="comment"> *</span></div>
<div class="line"><a id="l00060" name="l00060"></a><span class="lineno">   60</span><span class="comment"> * Welcome to the Flow project.  The documentation you&#39;re viewing has been generated using Doxygen directly from Flow</span></div>
<div class="line"><a id="l00061" name="l00061"></a><span class="lineno">   61</span><span class="comment"> * source code and comments.  I recommend reading the documentation of `namespace` ::flow as the starting point; then</span></div>
<div class="line"><a id="l00062" name="l00062"></a><span class="lineno">   62</span><span class="comment"> * that will direct one to the documentation of one or more of its sub-namespaces, depending on which Flow module(s)&#39;s</span></div>
<div class="line"><a id="l00063" name="l00063"></a><span class="lineno">   63</span><span class="comment"> * functionality interests that person.</span></div>
<div class="line"><a id="l00064" name="l00064"></a><span class="lineno">   64</span><span class="comment"> */</span></div>
<div class="line"><a id="l00065" name="l00065"></a><span class="lineno">   65</span> </div>
<div class="line"><a id="l00066" name="l00066"></a><span class="lineno">   66</span><span class="comment">/* We build in C++17 mode ourselves (as of this writing), but linking user shouldn&#39;t care about that so much.</span></div>
<div class="line"><a id="l00067" name="l00067"></a><span class="lineno">   67</span><span class="comment"> * The APIs and header-inlined stuff (templates, constexprs, possibly explicitly-inlined functions [though we avoid</span></div>
<div class="line"><a id="l00068" name="l00068"></a><span class="lineno">   68</span><span class="comment"> * those]), however, also requires C++17 or newer; and that applies to the linking user&#39;s `#include`ing .cpp file(s)!</span></div>
<div class="line"><a id="l00069" name="l00069"></a><span class="lineno">   69</span><span class="comment"> * Therefore enforce it by failing compile unless compiler&#39;s C++17 or newer mode is in use.</span></div>
<div class="line"><a id="l00070" name="l00070"></a><span class="lineno">   70</span><span class="comment"> *</span></div>
<div class="line"><a id="l00071" name="l00071"></a><span class="lineno">   71</span><span class="comment"> * Note this isn&#39;t academic; as of this writing there&#39;s at least a C++14-requiring constexpr feature in use in one</span></div>
<div class="line"><a id="l00072" name="l00072"></a><span class="lineno">   72</span><span class="comment"> * of the headers.  So at least C++14 has been required for ages in actual practice.  Later, notched it up to C++17</span></div>
<div class="line"><a id="l00073" name="l00073"></a><span class="lineno">   73</span><span class="comment"> * by similar logic.</span></div>
<div class="line"><a id="l00074" name="l00074"></a><span class="lineno">   74</span><span class="comment"> *</span></div>
<div class="line"><a id="l00075" name="l00075"></a><span class="lineno">   75</span><span class="comment"> * Update: We continue to target C++17 (by default) in our build -- but now also support (and, outside</span></div>
<div class="line"><a id="l00076" name="l00076"></a><span class="lineno">   76</span><span class="comment"> * the source code proper, test) C++20 mode build, albeit without using any C++20-only language or STL features.  It is</span></div>
<div class="line"><a id="l00077" name="l00077"></a><span class="lineno">   77</span><span class="comment"> * conceivable that at some point in the future we&#39;ll target C++20 by default (and drop support for C++17 and older).</span></div>
<div class="line"><a id="l00078" name="l00078"></a><span class="lineno">   78</span><span class="comment"> * Naturally at that point we&#39;d begin using C++20 language/STL features when convenient. */</span></div>
<div class="line"><a id="l00079" name="l00079"></a><span class="lineno">   79</span><span class="preprocessor">#if (!defined(__cplusplus)) || (__cplusplus &lt; 201703L)</span></div>
<div class="line"><a id="l00080" name="l00080"></a><span class="lineno">   80</span><span class="comment">// Would use static_assert(false), but... it&#39;s C++11 and later only.  So.</span></div>
<div class="line"><a id="l00081" name="l00081"></a><span class="lineno">   81</span><span class="preprocessor">#  error &quot;To compile a translation unit that `#include`s any flow/ API headers, use C++17 compile mode or later.&quot;</span></div>
<div class="line"><a id="l00082" name="l00082"></a><span class="lineno">   82</span><span class="preprocessor">#endif</span></div>
<div class="line"><a id="l00083" name="l00083"></a><span class="lineno">   83</span> </div>
<div class="line"><a id="l00084" name="l00084"></a><span class="lineno">   84</span><span class="comment">// Macros.  These (conceptually) belong to the `flow` namespace (hence the prefix for each macro).</span></div>
<div class="line"><a id="l00085" name="l00085"></a><span class="lineno">   85</span> </div>
<div class="line"><a id="l00086" name="l00086"></a><span class="lineno">   86</span><span class="preprocessor">#ifdef FLOW_DOXYGEN_ONLY </span><span class="comment">// Compiler ignores; Doxygen sees.</span></div>
<div class="line"><a id="l00087" name="l00087"></a><span class="lineno">   87</span><span class="comment"></span> </div>
<div class="line"><a id="l00088" name="l00088"></a><span class="lineno">   88</span><span class="comment">/// Macro that is defined if and only if the compiling environment is Linux.</span></div>
<div class="line"><a id="l00089" name="l00089"></a><span class="lineno"><a class="line" href="common_8hpp.html#abb2f9f3d34f909216637ac16e3321727">   89</a></span><span class="comment"></span><span class="preprocessor">#  define FLOW_OS_LINUX</span></div>
<div class="line"><a id="l00090" name="l00090"></a><span class="lineno">   90</span><span class="comment"></span> </div>
<div class="line"><a id="l00091" name="l00091"></a><span class="lineno">   91</span><span class="comment">/// Macro that is defined if and only if the compiling environment is Mac OS X or higher macOS (not iOS and such!).</span></div>
<div class="line"><a id="l00092" name="l00092"></a><span class="lineno"><a class="line" href="common_8hpp.html#ab38c55048f378ce506da9b5989b36dc5">   92</a></span><span class="comment"></span><span class="preprocessor">#  define FLOW_OS_MAC</span></div>
<div class="line"><a id="l00093" name="l00093"></a><span class="lineno">   93</span><span class="comment"></span> </div>
<div class="line"><a id="l00094" name="l00094"></a><span class="lineno">   94</span><span class="comment">/// Macro that is defined if and only if the compiling environment is Windows.</span></div>
<div class="line"><a id="l00095" name="l00095"></a><span class="lineno"><a class="line" href="common_8hpp.html#aa97a4a2066a1727fa67917638a569a34">   95</a></span><span class="comment"></span><span class="preprocessor">#  define FLOW_OS_WIN</span></div>
<div class="line"><a id="l00096" name="l00096"></a><span class="lineno">   96</span> </div>
<div class="line"><a id="l00097" name="l00097"></a><span class="lineno">   97</span><span class="preprocessor">#else </span><span class="comment">// if !defined(FLOW_DOXYGEN_ONLY)</span></div>
<div class="line"><a id="l00098" name="l00098"></a><span class="lineno">   98</span> </div>
<div class="line"><a id="l00099" name="l00099"></a><span class="lineno">   99</span><span class="comment">// Now the actual definitions compiler sees (Doxygen ignores).</span></div>
<div class="line"><a id="l00100" name="l00100"></a><span class="lineno">  100</span> </div>
<div class="line"><a id="l00101" name="l00101"></a><span class="lineno">  101</span><span class="comment">/* Used this delightful page for this logic:</span></div>
<div class="line"><a id="l00102" name="l00102"></a><span class="lineno">  102</span><span class="comment"> *   https://web.archive.org/web/20140625123925/http://nadeausoftware.com/articles/2012/01/c_c_tip_how_use_compiler_predefined_macros_detect_operating_system */</span></div>
<div class="line"><a id="l00103" name="l00103"></a><span class="lineno">  103</span><span class="preprocessor">#  ifdef __linux__</span></div>
<div class="line"><a id="l00104" name="l00104"></a><span class="lineno">  104</span><span class="preprocessor">#    define FLOW_OS_LINUX</span></div>
<div class="line"><a id="l00105" name="l00105"></a><span class="lineno">  105</span><span class="preprocessor">#  elif defined(__APPLE__) &amp;&amp; (TARGET_OS_MAC == 1)</span></div>
<div class="line"><a id="l00106" name="l00106"></a><span class="lineno">  106</span><span class="preprocessor">#    define FLOW_OS_MAC</span></div>
<div class="line"><a id="l00107" name="l00107"></a><span class="lineno">  107</span><span class="preprocessor">#  elif defined(_WIN32) || defined(_WIN64)</span></div>
<div class="line"><a id="l00108" name="l00108"></a><span class="lineno">  108</span><span class="preprocessor">#    define FLOW_OS_WIN</span></div>
<div class="line"><a id="l00109" name="l00109"></a><span class="lineno">  109</span><span class="preprocessor">#  endif</span></div>
<div class="line"><a id="l00110" name="l00110"></a><span class="lineno">  110</span> </div>
<div class="line"><a id="l00111" name="l00111"></a><span class="lineno">  111</span><span class="preprocessor">#endif </span><span class="comment">// elif !defined(FLOW_DOXYGEN_ONLY)</span></div>
<div class="line"><a id="l00112" name="l00112"></a><span class="lineno">  112</span><span class="comment"></span> </div>
<div class="line"><a id="l00113" name="l00113"></a><span class="lineno">  113</span><span class="comment">/**</span></div>
<div class="line"><a id="l00114" name="l00114"></a><span class="lineno">  114</span><span class="comment"> * Catch-all namespace for the Flow project: A collection of various production-quality modules written in modern</span></div>
<div class="line"><a id="l00115" name="l00115"></a><span class="lineno">  115</span><span class="comment"> * C++17, originally by ygoldfel.  (The very first version was in Boost-y C++03, back around 2010.  Later, ~2019, it</span></div>
<div class="line"><a id="l00116" name="l00116"></a><span class="lineno">  116</span><span class="comment"> * moved to C++14 in style and substance; and in 2022 to C++17 -- a relatively minor upgrade.)</span></div>
<div class="line"><a id="l00117" name="l00117"></a><span class="lineno">  117</span><span class="comment"> * While the modules are orthogonal to each other in terms of functionality</span></div>
<div class="line"><a id="l00118" name="l00118"></a><span class="lineno">  118</span><span class="comment"> * provided, they all share a common set of stylistic conventions and happen to use each other internally; hence</span></div>
<div class="line"><a id="l00119" name="l00119"></a><span class="lineno">  119</span><span class="comment"> * they are distributed together as of this writing.</span></div>
<div class="line"><a id="l00120" name="l00120"></a><span class="lineno">  120</span><span class="comment"> *</span></div>
<div class="line"><a id="l00121" name="l00121"></a><span class="lineno">  121</span><span class="comment"> * From the user&#39;s perspective, one should view this namespace as the &quot;root,&quot; meaning it consists of two parts:</span></div>
<div class="line"><a id="l00122" name="l00122"></a><span class="lineno">  122</span><span class="comment"> *   - Sub-namespaces (like flow::log, flow::util, flow::async, flow::net_flow),</span></div>
<div class="line"><a id="l00123" name="l00123"></a><span class="lineno">  123</span><span class="comment"> *     each of which represents a *Flow module* providing certain</span></div>
<div class="line"><a id="l00124" name="l00124"></a><span class="lineno">  124</span><span class="comment"> *     grouped functionality.  Each module is self-contained from the point of view of the user, meaning:</span></div>
<div class="line"><a id="l00125" name="l00125"></a><span class="lineno">  125</span><span class="comment"> *     While the various modules may use each other internally (and hence cannot be easily distributed separately), from</span></div>
<div class="line"><a id="l00126" name="l00126"></a><span class="lineno">  126</span><span class="comment"> *     user&#39;s perspective each one can be directly `include`d/referenced without directly `include`ing/referring to the</span></div>
<div class="line"><a id="l00127" name="l00127"></a><span class="lineno">  127</span><span class="comment"> *     others.  E.g., one can directly reference `namespace log` *and/or* `namespace util` *and/or* `namespace net_flow`</span></div>
<div class="line"><a id="l00128" name="l00128"></a><span class="lineno">  128</span><span class="comment"> *     *and/or* ....  Further documentation can be found in the doc headers for each individual sub-namespace.</span></div>
<div class="line"><a id="l00129" name="l00129"></a><span class="lineno">  129</span><span class="comment"> *   - Symbols directly in `flow`: The absolute most basic, commonly used symbols (such as `uint32_t` or `Error_code`).</span></div>
<div class="line"><a id="l00130" name="l00130"></a><span class="lineno">  130</span><span class="comment"> *     There should be only a handful of these, and they are likely to be small.</span></div>
<div class="line"><a id="l00131" name="l00131"></a><span class="lineno">  131</span><span class="comment"> *     - In particular this includes `enum class Flow_log_component` which defines the set of possible</span></div>
<div class="line"><a id="l00132" name="l00132"></a><span class="lineno">  132</span><span class="comment"> *       flow::log::Component values logged from within all modules of Flow (again, including flow::util, flow::async,</span></div>
<div class="line"><a id="l00133" name="l00133"></a><span class="lineno">  133</span><span class="comment"> *       flow::net_flow, etc.).  See end of common.hpp.</span></div>
<div class="line"><a id="l00134" name="l00134"></a><span class="lineno">  134</span><span class="comment"> *</span></div>
<div class="line"><a id="l00135" name="l00135"></a><span class="lineno">  135</span><span class="comment"> * Reiterating: Non-`namespace` symbols directly inside `namespace flow` are to be only extremely ubiquitous items</span></div>
<div class="line"><a id="l00136" name="l00136"></a><span class="lineno">  136</span><span class="comment"> * such as the basic integer types and the log component `enum`.  Anything beyond that should go into a sub-`namespace`</span></div>
<div class="line"><a id="l00137" name="l00137"></a><span class="lineno">  137</span><span class="comment"> * of `flow`; if it is something miscellaneous then put it into flow::util.</span></div>
<div class="line"><a id="l00138" name="l00138"></a><span class="lineno">  138</span><span class="comment"> *</span></div>
<div class="line"><a id="l00139" name="l00139"></a><span class="lineno">  139</span><span class="comment"> * Here we summarize topics relevant to all of Flow.  It is recommend one reads this before using any individual module,</span></div>
<div class="line"><a id="l00140" name="l00140"></a><span class="lineno">  140</span><span class="comment"> * for topics like file organization and style conventions, topics arguably not of huge practical value right away.</span></div>
<div class="line"><a id="l00141" name="l00141"></a><span class="lineno">  141</span><span class="comment"> * However, all the actual functionality is in the sub-modules, so once you&#39;re ready to actually do stuff, I reiterate:</span></div>
<div class="line"><a id="l00142" name="l00142"></a><span class="lineno">  142</span><span class="comment"> * See the list of sub-namespaces of `flow` and start with the doc header of the one(s) of interest to you.</span></div>
<div class="line"><a id="l00143" name="l00143"></a><span class="lineno">  143</span><span class="comment"> *</span></div>
<div class="line"><a id="l00144" name="l00144"></a><span class="lineno">  144</span><span class="comment"> * Documentation / Doxygen</span></div>
<div class="line"><a id="l00145" name="l00145"></a><span class="lineno">  145</span><span class="comment"> * -----------------------</span></div>
<div class="line"><a id="l00146" name="l00146"></a><span class="lineno">  146</span><span class="comment"> *</span></div>
<div class="line"><a id="l00147" name="l00147"></a><span class="lineno">  147</span><span class="comment"> * All code in the project proper follows a high standard of documentation, almost solely via comments therein</span></div>
<div class="line"><a id="l00148" name="l00148"></a><span class="lineno">  148</span><span class="comment"> * (as opposed to ancillary doc files/READMEs/etc.).  Additionally, a subset of comments are Doxygen-targeted,</span></div>
<div class="line"><a id="l00149" name="l00149"></a><span class="lineno">  149</span><span class="comment"> * meaning the comment starts with a special character sequence to cause the Doxygen utility to treat that comment</span></div>
<div class="line"><a id="l00150" name="l00150"></a><span class="lineno">  150</span><span class="comment"> * as a doc header for a nearby symbol (class, method, etc.).  (If you&#39;re not familiar with Doxygen: It&#39;s like Javadoc</span></div>
<div class="line"><a id="l00151" name="l00151"></a><span class="lineno">  151</span><span class="comment"> * but better -- although mostly compatible with Javadoc-targeted comments as well -- not that we care about that.)</span></div>
<div class="line"><a id="l00152" name="l00152"></a><span class="lineno">  152</span><span class="comment"> *</span></div>
<div class="line"><a id="l00153" name="l00153"></a><span class="lineno">  153</span><span class="comment"> * From the same source code (the entire Flow tree) 2 (two) web docs are generated by Doxygen utility -- depending on</span></div>
<div class="line"><a id="l00154" name="l00154"></a><span class="lineno">  154</span><span class="comment"> * which of the 2 Doxygen configuration files is chosen.  You can determine which web docs you&#39;re reading currently</span></div>
<div class="line"><a id="l00155" name="l00155"></a><span class="lineno">  155</span><span class="comment"> * (if indeed you are doing that, as opposed to reading raw code) via the wording of the title/header in every web page:</span></div>
<div class="line"><a id="l00156" name="l00156"></a><span class="lineno">  156</span><span class="comment"> *   - *Flow project: Full implementation reference*: This scans every header and translation unit file, including</span></div>
<div class="line"><a id="l00157" name="l00157"></a><span class="lineno">  157</span><span class="comment"> *     those in detail/ sub-directories at all levels; and all Doxygen-targeted comments (including this one)</span></div>
<div class="line"><a id="l00158" name="l00158"></a><span class="lineno">  158</span><span class="comment"> *     are fully scanned.  Full browsable source code is included in the output also.  As a result, it&#39;s basically</span></div>
<div class="line"><a id="l00159" name="l00159"></a><span class="lineno">  159</span><span class="comment"> *     an ultra-nice viewer of the entire source code (implementation included), with special emphasis on</span></div>
<div class="line"><a id="l00160" name="l00160"></a><span class="lineno">  160</span><span class="comment"> *     doc headers such as this one.</span></div>
<div class="line"><a id="l00161" name="l00161"></a><span class="lineno">  161</span><span class="comment"> *   - *Flow project: Public API*: Only headers are scanned; and all detail/ sub-directories at all levels are ignored.</span></div>
<div class="line"><a id="l00162" name="l00162"></a><span class="lineno">  162</span><span class="comment"> *     Additionally, any text following the (optional) `&quot;@internal&quot;` Doxygen command within each given Doxygen comment</span></div>
<div class="line"><a id="l00163" name="l00163"></a><span class="lineno">  163</span><span class="comment"> *     is ignored.  Browsable source code is omitted.  As a result, a clean public API documentation is generated with</span></div>
<div class="line"><a id="l00164" name="l00164"></a><span class="lineno">  164</span><span class="comment"> *     no &quot;fat.&quot;</span></div>
<div class="line"><a id="l00165" name="l00165"></a><span class="lineno">  165</span><span class="comment"> *</span></div>
<div class="line"><a id="l00166" name="l00166"></a><span class="lineno">  166</span><span class="comment"> * While an important (achieved) goal is to keep the documentation of the library (internal and external, as noted)</span></div>
<div class="line"><a id="l00167" name="l00167"></a><span class="lineno">  167</span><span class="comment"> * self-contained -- within the source code or auto-generated by taking that source code as input -- nevertheless some</span></div>
<div class="line"><a id="l00168" name="l00168"></a><span class="lineno">  168</span><span class="comment"> * satellite documentation is likely to exist; for example to cover such things as the logistical state of the project,</span></div>
<div class="line"><a id="l00169" name="l00169"></a><span class="lineno">  169</span><span class="comment"> * its test harness, perhaps the license, etc.  Look outside the root src/flow directory.</span></div>
<div class="line"><a id="l00170" name="l00170"></a><span class="lineno">  170</span><span class="comment"> *</span></div>
<div class="line"><a id="l00171" name="l00171"></a><span class="lineno">  171</span><span class="comment"> * @todo As of this writing the *exact* nature of where the project will permanently reside (and who will maintain it</span></div>
<div class="line"><a id="l00172" name="l00172"></a><span class="lineno">  172</span><span class="comment"> * vs. use it) is in flux.  Therefore for now I have removed the section covering certain topics and replaced it with</span></div>
<div class="line"><a id="l00173" name="l00173"></a><span class="lineno">  173</span><span class="comment"> * the to-do you&#39;re reading.  This should be undone when things settle down (obviously ensuring the brought-back section</span></div>
<div class="line"><a id="l00174" name="l00174"></a><span class="lineno">  174</span><span class="comment"> * is made accurate).  The topics to cover: `&quot;@author&quot;` (including contact info); GitHub/other address indicating where</span></div>
<div class="line"><a id="l00175" name="l00175"></a><span class="lineno">  175</span><span class="comment"> * to browse the project source; link(s) to the latest auto-generated web docs (if any); a section on the</span></div>
<div class="line"><a id="l00176" name="l00176"></a><span class="lineno">  176</span><span class="comment"> * history of the project; and licensing info (if deemed needed) or pointer to it.  (Reminder: Also update any</span></div>
<div class="line"><a id="l00177" name="l00177"></a><span class="lineno">  177</span><span class="comment"> * similar sections of the historically significant net_flow::Node doc header.)</span></div>
<div class="line"><a id="l00178" name="l00178"></a><span class="lineno">  178</span><span class="comment"> *</span></div>
<div class="line"><a id="l00179" name="l00179"></a><span class="lineno">  179</span><span class="comment"> * @todo Since Flow gained its first users beyond the original author, some Flow-adjacent code has been written from</span></div>
<div class="line"><a id="l00180" name="l00180"></a><span class="lineno">  180</span><span class="comment"> * which Flow can benefit, including a potential `io` module/namespace for general networking/local I/O.</span></div>
<div class="line"><a id="l00181" name="l00181"></a><span class="lineno">  181</span><span class="comment"> * (Flow itself continued to be developed, but some features were added</span></div>
<div class="line"><a id="l00182" name="l00182"></a><span class="lineno">  182</span><span class="comment"> * elsewhere for expediency; this is a reminder to factor them out into Flow for the benefit of</span></div>
<div class="line"><a id="l00183" name="l00183"></a><span class="lineno">  183</span><span class="comment"> * all.)  Some features to migrate here might be: boost.asio extensions to UDP receive APIs to obtain receipt time</span></div>
<div class="line"><a id="l00184" name="l00184"></a><span class="lineno">  184</span><span class="comment"> * stamps and destination IP (`recvmsg()` with ancillary data extensions) and to receive multiple datagrams in one</span></div>
<div class="line"><a id="l00185" name="l00185"></a><span class="lineno">  185</span><span class="comment"> * call (`recvmmsg()`); boost.asio-adjacent facility to add custom socket options similarly to how boost.asio does it</span></div>
<div class="line"><a id="l00186" name="l00186"></a><span class="lineno">  186</span><span class="comment"> * internally; boost.asio support for (local) transmission of native socket handles and security data over stream</span></div>
<div class="line"><a id="l00187" name="l00187"></a><span class="lineno">  187</span><span class="comment"> * sockets (`SCM_RIGHTS`, etc.).</span></div>
<div class="line"><a id="l00188" name="l00188"></a><span class="lineno">  188</span><span class="comment"> *</span></div>
<div class="line"><a id="l00189" name="l00189"></a><span class="lineno">  189</span><span class="comment"> * Using Flow modules</span></div>
<div class="line"><a id="l00190" name="l00190"></a><span class="lineno">  190</span><span class="comment"> * ------------------</span></div>
<div class="line"><a id="l00191" name="l00191"></a><span class="lineno">  191</span><span class="comment"> *</span></div>
<div class="line"><a id="l00192" name="l00192"></a><span class="lineno">  192</span><span class="comment"> * This section discusses usability topics that apply to all Flow modules including hopefully any future ones but</span></div>
<div class="line"><a id="l00193" name="l00193"></a><span class="lineno">  193</span><span class="comment"> * definitely all existing ones as of this writing.</span></div>
<div class="line"><a id="l00194" name="l00194"></a><span class="lineno">  194</span><span class="comment"> *</span></div>
<div class="line"><a id="l00195" name="l00195"></a><span class="lineno">  195</span><span class="comment"> * ### Error reporting ###</span></div>
<div class="line"><a id="l00196" name="l00196"></a><span class="lineno">  196</span><span class="comment"> * Similarly to boost.asio, all public methods that may return errors can either do so via an</span></div>
<div class="line"><a id="l00197" name="l00197"></a><span class="lineno">  197</span><span class="comment"> * error code or an exception encapsulating that same error code.  If user passes in non-null pointer to a</span></div>
<div class="line"><a id="l00198" name="l00198"></a><span class="lineno">  198</span><span class="comment"> * flow::Error_code variable, the latter is set to success (falsy) or a specific failure (truthy `enum` value).  If</span></div>
<div class="line"><a id="l00199" name="l00199"></a><span class="lineno">  199</span><span class="comment"> * user passes in null pointer, an exception `exc` is thrown only in case of error and will encapsulate that error code</span></div>
<div class="line"><a id="l00200" name="l00200"></a><span class="lineno">  200</span><span class="comment"> * (accessible via `exc.code()`).</span></div>
<div class="line"><a id="l00201" name="l00201"></a><span class="lineno">  201</span><span class="comment"> *</span></div>
<div class="line"><a id="l00202" name="l00202"></a><span class="lineno">  202</span><span class="comment"> * For details about error reporting, see doc headers for flow::Error_code (spoiler alert: a mere alias to</span></div>
<div class="line"><a id="l00203" name="l00203"></a><span class="lineno">  203</span><span class="comment"> * `boost::system::error_code`) and `namespace` flow::error.</span></div>
<div class="line"><a id="l00204" name="l00204"></a><span class="lineno">  204</span><span class="comment"> *</span></div>
<div class="line"><a id="l00205" name="l00205"></a><span class="lineno">  205</span><span class="comment"> * ### Logging ###</span></div>
<div class="line"><a id="l00206" name="l00206"></a><span class="lineno">  206</span><span class="comment"> * The flow::log namespace (see especially log::Logger and the various `FLOW_LOG_...*()` macros in</span></div>
<div class="line"><a id="l00207" name="l00207"></a><span class="lineno">  207</span><span class="comment"> * log/log.hpp) provides a logging facility -- used by Flow modules&#39; often-extensive logging, and equally available</span></div>
<div class="line"><a id="l00208" name="l00208"></a><span class="lineno">  208</span><span class="comment"> * to the Flow user.  Ultimately, you may tweak the log level and then observe the given Flow module&#39;s internal behavior</span></div>
<div class="line"><a id="l00209" name="l00209"></a><span class="lineno">  209</span><span class="comment"> * to whatever level of detail you desire.  Similarly, as the user, you may use this system for your own logging,</span></div>
<div class="line"><a id="l00210" name="l00210"></a><span class="lineno">  210</span><span class="comment"> * even if you use no Flow module other than flow::log itself.  Either way, you can hook up flow::log to log via your</span></div>
<div class="line"><a id="l00211" name="l00211"></a><span class="lineno">  211</span><span class="comment"> * own log output device in arbitrary fashion (e.g., save the log messages in a database, if that&#39;s what you want).</span></div>
<div class="line"><a id="l00212" name="l00212"></a><span class="lineno">  212</span><span class="comment"> *</span></div>
<div class="line"><a id="l00213" name="l00213"></a><span class="lineno">  213</span><span class="comment"> * For details about logging, see doc header for `namespace` flow::log.</span></div>
<div class="line"><a id="l00214" name="l00214"></a><span class="lineno">  214</span><span class="comment"> *</span></div>
<div class="line"><a id="l00215" name="l00215"></a><span class="lineno">  215</span><span class="comment"> * @internal</span></div>
<div class="line"><a id="l00216" name="l00216"></a><span class="lineno">  216</span><span class="comment"> *</span></div>
<div class="line"><a id="l00217" name="l00217"></a><span class="lineno">  217</span><span class="comment"> * Implementation notes</span></div>
<div class="line"><a id="l00218" name="l00218"></a><span class="lineno">  218</span><span class="comment"> * --------------------</span></div>
<div class="line"><a id="l00219" name="l00219"></a><span class="lineno">  219</span><span class="comment"> *</span></div>
<div class="line"><a id="l00220" name="l00220"></a><span class="lineno">  220</span><span class="comment"> * There is a high standard of consistency and style, as well as documentation, in Flow.  Before making changes to</span></div>
<div class="line"><a id="l00221" name="l00221"></a><span class="lineno">  221</span><span class="comment"> * the code, you must read doc-coding_style.cpp.</span></div>
<div class="line"><a id="l00222" name="l00222"></a><span class="lineno">  222</span><span class="comment"> *</span></div>
<div class="line"><a id="l00223" name="l00223"></a><span class="lineno">  223</span><span class="comment"> * ### Source file tree organization ###</span></div>
<div class="line"><a id="l00224" name="l00224"></a><span class="lineno">  224</span><span class="comment"> * See doc-coding_style.cpp which covers this topic.</span></div>
<div class="line"><a id="l00225" name="l00225"></a><span class="lineno">  225</span><span class="comment"> *</span></div>
<div class="line"><a id="l00226" name="l00226"></a><span class="lineno">  226</span><span class="comment"> * ### Libraries used; Boost ###</span></div>
<div class="line"><a id="l00227" name="l00227"></a><span class="lineno">  227</span><span class="comment"> * We use STL and several Boost libraries (notably boost.asio) extensively.</span></div>
<div class="line"><a id="l00228" name="l00228"></a><span class="lineno">  228</span><span class="comment"> * See doc-coding_style.cpp which covers this topic.</span></div>
<div class="line"><a id="l00229" name="l00229"></a><span class="lineno">  229</span><span class="comment"> *</span></div>
<div class="line"><a id="l00230" name="l00230"></a><span class="lineno">  230</span><span class="comment"> * ### Exceptions ###</span></div>
<div class="line"><a id="l00231" name="l00231"></a><span class="lineno">  231</span><span class="comment"> * For reasons of speed (hearsay or reputational though they may be) we avoid exception-throwing</span></div>
<div class="line"><a id="l00232" name="l00232"></a><span class="lineno">  232</span><span class="comment"> * boost.asio routines inside the modules&#39; implementations, even though using them would make the code a bit simpler</span></div>
<div class="line"><a id="l00233" name="l00233"></a><span class="lineno">  233</span><span class="comment"> * in many areas.  Similarly, we avoid throwing our own exceptions only to catch them higher in the back-trace.</span></div>
<div class="line"><a id="l00234" name="l00234"></a><span class="lineno">  234</span><span class="comment"> * In both cases, we typically use error codes/return values.  These are not absolute/hard rules, as exceptions may be</span></div>
<div class="line"><a id="l00235" name="l00235"></a><span class="lineno">  235</span><span class="comment"> * used where minuscule speed improvements are immaterial (like the initialization and shutdown of a long-lived object</span></div>
<div class="line"><a id="l00236" name="l00236"></a><span class="lineno">  236</span><span class="comment"> * such as net_flow::Node).</span></div>
<div class="line"><a id="l00237" name="l00237"></a><span class="lineno">  237</span><span class="comment"> *</span></div>
<div class="line"><a id="l00238" name="l00238"></a><span class="lineno">  238</span><span class="comment"> * After a recent look at performance implications of exceptions, the following is the basic conclusion: Exceptions have</span></div>
<div class="line"><a id="l00239" name="l00239"></a><span class="lineno">  239</span><span class="comment"> * no processor cycle cost, unless actually thrown, in which case the perf cost can be non-trivial.  Since we consider</span></div>
<div class="line"><a id="l00240" name="l00240"></a><span class="lineno">  240</span><span class="comment"> * internal performance of paramount importance, we generally avoid throwing exceptions -- only to catch them</span></div>
<div class="line"><a id="l00241" name="l00241"></a><span class="lineno">  241</span><span class="comment"> * internally -- as noted in the preceding paragraph.  Arguably such situations are rare anyway, so using an exception</span></div>
<div class="line"><a id="l00242" name="l00242"></a><span class="lineno">  242</span><span class="comment"> * internally wouldn&#39;t actually slow anything down, but we haven&#39;t performed a code audit to verify that stipulation;</span></div>
<div class="line"><a id="l00243" name="l00243"></a><span class="lineno">  243</span><span class="comment"> * and in the meantime the consistent avoidance of using internally caught exceptions has proved to be a very reasonable</span></div>
<div class="line"><a id="l00244" name="l00244"></a><span class="lineno">  244</span><span class="comment"> * policy.  (For some modules this may be arguably mostly moot: Consider flow::net_flow specifically: Since --</span></div>
<div class="line"><a id="l00245" name="l00245"></a><span class="lineno">  245</span><span class="comment"> * internally -- mostly boost.asio `async_*()` methods are used, and those</span></div>
<div class="line"><a id="l00246" name="l00246"></a><span class="lineno">  246</span><span class="comment"> * by definition report errors as codes passed into async handler functions; whether to use an exception or not is</span></div>
<div class="line"><a id="l00247" name="l00247"></a><span class="lineno">  247</span><span class="comment"> * an ill-formed question in all such situations.)  We recommend this practice continue, until there&#39;s a specific reason</span></div>
<div class="line"><a id="l00248" name="l00248"></a><span class="lineno">  248</span><span class="comment"> * to reconsider.</span></div>
<div class="line"><a id="l00249" name="l00249"></a><span class="lineno">  249</span><span class="comment"> *</span></div>
<div class="line"><a id="l00250" name="l00250"></a><span class="lineno">  250</span><span class="comment"> * See doc-coding_style.cpp for more discussion of error handling and exceptions.</span></div>
<div class="line"><a id="l00251" name="l00251"></a><span class="lineno">  251</span><span class="comment"> *</span></div>
<div class="line"><a id="l00252" name="l00252"></a><span class="lineno">  252</span><span class="comment"> * Code style guidelines</span></div>
<div class="line"><a id="l00253" name="l00253"></a><span class="lineno">  253</span><span class="comment"> * ---------------------</span></div>
<div class="line"><a id="l00254" name="l00254"></a><span class="lineno">  254</span><span class="comment"> *</span></div>
<div class="line"><a id="l00255" name="l00255"></a><span class="lineno">  255</span><span class="comment"> * ### General coding style requirements ###</span></div>
<div class="line"><a id="l00256" name="l00256"></a><span class="lineno">  256</span><span class="comment"> * The formal guidelines are in doc-coding_style.cpp; read that file please.</span></div>
<div class="line"><a id="l00257" name="l00257"></a><span class="lineno">  257</span><span class="comment"> *</span></div>
<div class="line"><a id="l00258" name="l00258"></a><span class="lineno">  258</span><span class="comment"> * ### Documentation guidelines ###</span></div>
<div class="line"><a id="l00259" name="l00259"></a><span class="lineno">  259</span><span class="comment"> * The standard for documentation of Flow modules is that someone reading the source code, and nothing else, would</span></div>
<div class="line"><a id="l00260" name="l00260"></a><span class="lineno">  260</span><span class="comment"> * be able to understand that code (modulo having the intellectual sophistication/experience w/r/t the subject</span></div>
<div class="line"><a id="l00261" name="l00261"></a><span class="lineno">  261</span><span class="comment"> * matter, of course).  Simple but quite a task given how much code there is and the complexity.  We also</span></div>
<div class="line"><a id="l00262" name="l00262"></a><span class="lineno">  262</span><span class="comment"> * produce Doxygen output (2 web pages, as of this writing) by running the code through Doxygen.</span></div>
<div class="line"><a id="l00263" name="l00263"></a><span class="lineno">  263</span><span class="comment"> *</span></div>
<div class="line"><a id="l00264" name="l00264"></a><span class="lineno">  264</span><span class="comment"> * @see More on the technicalities of how we run Doxygen, and the philosophy behind all of that, can be found</span></div>
<div class="line"><a id="l00265" name="l00265"></a><span class="lineno">  265</span><span class="comment"> * in a `doc/` or similar directory outside src/flow.  It&#39;s rare something pertinent to the source code</span></div>
<div class="line"><a id="l00266" name="l00266"></a><span class="lineno">  266</span><span class="comment"> * is not IN the source code (i.e., right here somewhere), but the README explains why that rare choice is</span></div>
<div class="line"><a id="l00267" name="l00267"></a><span class="lineno">  267</span><span class="comment"> * made (among many more practical/interesting things).  This is worth reading if you&#39;ll be contributing to the</span></div>
<div class="line"><a id="l00268" name="l00268"></a><span class="lineno">  268</span><span class="comment"> * code.</span></div>
<div class="line"><a id="l00269" name="l00269"></a><span class="lineno">  269</span><span class="comment"> *</span></div>
<div class="line"><a id="l00270" name="l00270"></a><span class="lineno">  270</span><span class="comment"> * The actual guidelines are, as above, in doc-coding_style.cpp; read that file please.</span></div>
<div class="line"><a id="l00271" name="l00271"></a><span class="lineno">  271</span><span class="comment"> *</span></div>
<div class="line"><a id="l00272" name="l00272"></a><span class="lineno">  272</span><span class="comment"> * @todo Possibly document exceptions thrown explicitly via the Doxygen keyword meant for this purpose: `&quot;@throws&quot;`.</span></div>
<div class="line"><a id="l00273" name="l00273"></a><span class="lineno">  273</span><span class="comment"> * Currently when we document explicitly throwing an exception, it is ALWAYS a flow::error::Runtime_error</span></div>
<div class="line"><a id="l00274" name="l00274"></a><span class="lineno">  274</span><span class="comment"> * encapsulating a flow::Error_code (which is an `int`-like error code).  This is very explicitly documented,</span></div>
<div class="line"><a id="l00275" name="l00275"></a><span class="lineno">  275</span><span class="comment"> * but technically Doxygen has a keyword which will generate a special little readout for the exception</span></div>
<div class="line"><a id="l00276" name="l00276"></a><span class="lineno">  276</span><span class="comment"> * (similarly as for each parameter, etc.).  We don&#39;t use that keyword.  We probably should, though this</span></div>
<div class="line"><a id="l00277" name="l00277"></a><span class="lineno">  277</span><span class="comment"> * isn&#39;t totally cut-and-dried.  Consider that we already document the exception on the `err_code` parameter</span></div>
<div class="line"><a id="l00278" name="l00278"></a><span class="lineno">  278</span><span class="comment"> * in every case; so no information would really be gained (only arguably nicer formatting).  On the other hand,</span></div>
<div class="line"><a id="l00279" name="l00279"></a><span class="lineno">  279</span><span class="comment"> * the code would be somewhat more verbose (and boiler-platey, since each already boiler-platey `err_code`</span></div>
<div class="line"><a id="l00280" name="l00280"></a><span class="lineno">  280</span><span class="comment"> * comment snippet would essentially grow in size).  Furthermore, if we document this explicit exception, one might</span></div>
<div class="line"><a id="l00281" name="l00281"></a><span class="lineno">  281</span><span class="comment"> * say it behooves us to now document all the other possible sources of exceptions such as `std::bad_alloc` when</span></div>
<div class="line"><a id="l00282" name="l00282"></a><span class="lineno">  282</span><span class="comment"> * running out of heap memory.  Perhaps then we have to talk about constructor-throwing-exception behavior and</span></div>
<div class="line"><a id="l00283" name="l00283"></a><span class="lineno">  283</span><span class="comment"> * other C++ technicalities to do with exceptions.  Do we really want to enter that land?  I think maybe not;</span></div>
<div class="line"><a id="l00284" name="l00284"></a><span class="lineno">  284</span><span class="comment"> * consider just leaving it alone.  Though, maybe I&#39;m over-dramatizing the impact of adding a `&quot;@throws&quot;`</span></div>
<div class="line"><a id="l00285" name="l00285"></a><span class="lineno">  285</span><span class="comment"> * section on our various flow::error::Runtime_error-throwing methods.  Well, it&#39;s a to-do; decide later.</span></div>
<div class="line"><a id="l00286" name="l00286"></a><span class="lineno">  286</span><span class="comment"> *</span></div>
<div class="line"><a id="l00287" name="l00287"></a><span class="lineno">  287</span><span class="comment"> * To-dos and future features</span></div>
<div class="line"><a id="l00288" name="l00288"></a><span class="lineno">  288</span><span class="comment"> * --------------------------</span></div>
<div class="line"><a id="l00289" name="l00289"></a><span class="lineno">  289</span><span class="comment"> *</span></div>
<div class="line"><a id="l00290" name="l00290"></a><span class="lineno">  290</span><span class="comment"> * @todo The comments (as of this writing, all written by me, ygoldfel) in this library could use an edit to make</span></div>
<div class="line"><a id="l00291" name="l00291"></a><span class="lineno">  291</span><span class="comment"> * them briefer.  (I&#39;ve found even a self-edit by me, with that express purpose, often does wonders.)  Background:</span></div>
<div class="line"><a id="l00292" name="l00292"></a><span class="lineno">  292</span><span class="comment"> * I write very extensive comments.  I am quite convinced this is superior (far superior even) to next-to-no comments;</span></div>
<div class="line"><a id="l00293" name="l00293"></a><span class="lineno">  293</span><span class="comment"> * and to the average amount of comments one tends to see in production code.  *That said*, the top code review</span></div>
<div class="line"><a id="l00294" name="l00294"></a><span class="lineno">  294</span><span class="comment"> * feedback I receive (not here specifically but in general) is that my comments tend to be too &quot;discursive&quot; (consisting</span></div>
<div class="line"><a id="l00295" name="l00295"></a><span class="lineno">  295</span><span class="comment"> * of discourse) and/or at times unnecessarily in-depth.  Discursive = as if I am talking to the reader (many prefer</span></div>
<div class="line"><a id="l00296" name="l00296"></a><span class="lineno">  296</span><span class="comment"> * a terser, more formal style).  Too in-depth = tends to go into history, related issues, future work, etc.</span></div>
<div class="line"><a id="l00297" name="l00297"></a><span class="lineno">  297</span><span class="comment"> * (these elements can remain but can be cut down significant without losing much substance).</span></div>
<div class="line"><a id="l00298" name="l00298"></a><span class="lineno">  298</span><span class="comment"> * In other words, there should be a happy middle in terms of comment volume, and this can</span></div>
<div class="line"><a id="l00299" name="l00299"></a><span class="lineno">  299</span><span class="comment"> * be achieved by a comment edit run by Yuri or someone else (if reviewed by Yuri).  To be clear, I believe this middle</span></div>
<div class="line"><a id="l00300" name="l00300"></a><span class="lineno">  300</span><span class="comment"> * ground is to be closer to the status quo than to the average amount of comments in other projects.</span></div>
<div class="line"><a id="l00301" name="l00301"></a><span class="lineno">  301</span><span class="comment"> *</span></div>
<div class="line"><a id="l00302" name="l00302"></a><span class="lineno">  302</span><span class="comment"> * @todo Be more specific (cite date) when writing &quot;as of this writing.&quot;</span></div>
<div class="line"><a id="l00303" name="l00303"></a><span class="lineno">  303</span><span class="comment"> * I use a rhetorical trick when commenting the state of something that may not continue to be the case.</span></div>
<div class="line"><a id="l00304" name="l00304"></a><span class="lineno">  304</span><span class="comment"> * Though I do avoid writing such things, often it is necessary; in that case I usually write &quot;as of this writing&quot; or</span></div>
<div class="line"><a id="l00305" name="l00305"></a><span class="lineno">  305</span><span class="comment"> * something very similarly worded.  That&#39;s fine and essentially the best one can do.  It means technically the</span></div>
<div class="line"><a id="l00306" name="l00306"></a><span class="lineno">  306</span><span class="comment"> * statement won&#39;t become false, even if the &quot;sub-statement&quot; (the thing that was true when written) does become false.</span></div>
<div class="line"><a id="l00307" name="l00307"></a><span class="lineno">  307</span><span class="comment"> * However, obviously, to the reader of the comment at that later time, that&#39;s little consolation: they&#39;re still reading</span></div>
<div class="line"><a id="l00308" name="l00308"></a><span class="lineno">  308</span><span class="comment"> * a possibly false statement and will want to know what the situation is THEN, or &quot;as of the reading,&quot; to to speak.</span></div>
<div class="line"><a id="l00309" name="l00309"></a><span class="lineno">  309</span><span class="comment"> * In order to at least try to be helpful, in those cases a date (numeric month/year -- like 4/2017 -- should be</span></div>
<div class="line"><a id="l00310" name="l00310"></a><span class="lineno">  310</span><span class="comment"> * sufficient in most cases) should be supplied.  The to-do is to convert all &quot;as of this writing&quot; instances -- and</span></div>
<div class="line"><a id="l00311" name="l00311"></a><span class="lineno">  311</span><span class="comment"> * to always add a date when writing new instances of &quot;as of this writing.&quot;  The to-do can be removed once the</span></div>
<div class="line"><a id="l00312" name="l00312"></a><span class="lineno">  312</span><span class="comment"> * conversion is completed.  Example: this to-do has not been completed as of this writing (11/2017).</span></div>
<div class="line"><a id="l00313" name="l00313"></a><span class="lineno">  313</span><span class="comment"> * (Side note: possibly goes without saying, but one is free to explain to an arbitrary degree of detail why something</span></div>
<div class="line"><a id="l00314" name="l00314"></a><span class="lineno">  314</span><span class="comment"> * is true as of that writing, and how/why/when it might change.  This to-do covers those cases where no such</span></div>
<div class="line"><a id="l00315" name="l00315"></a><span class="lineno">  315</span><span class="comment"> * explanation is written.  It would be impractically verbose to get into speculative detail for every</span></div>
<div class="line"><a id="l00316" name="l00316"></a><span class="lineno">  316</span><span class="comment"> * as-of-this-writing instance; so at least a date should thus be inserted.)</span></div>
<div class="line"><a id="l00317" name="l00317"></a><span class="lineno">  317</span><span class="comment"> *</span></div>
<div class="line"><a id="l00318" name="l00318"></a><span class="lineno">  318</span><span class="comment"> * @todo There are some boost.thread &quot;interruption points&quot; throughout the code, so we should</span></div>
<div class="line"><a id="l00319" name="l00319"></a><span class="lineno">  319</span><span class="comment"> * investigate whether we must catch `boost::thread_interrupted` in those spots, or what...?</span></div>
<div class="line"><a id="l00320" name="l00320"></a><span class="lineno">  320</span><span class="comment"> *</span></div>
<div class="line"><a id="l00321" name="l00321"></a><span class="lineno">  321</span><span class="comment"> * @todo Inline things:  Or just use `gcc -O3` (and non-`gcc` equivalents) for prettier/faster-to-compile</span></div>
<div class="line"><a id="l00322" name="l00322"></a><span class="lineno">  322</span><span class="comment"> * code?  The latter is definitely tempting if it works sufficiently well.  So far we&#39;ve been using</span></div>
<div class="line"><a id="l00323" name="l00323"></a><span class="lineno">  323</span><span class="comment"> * `gcc -O3` and equivalents, and it seems to be working well (turning off inlining results in huge</span></div>
<div class="line"><a id="l00324" name="l00324"></a><span class="lineno">  324</span><span class="comment"> * performance losses).  Still, I am not sure if it would be better to explicitly `inline` functions</span></div>
<div class="line"><a id="l00325" name="l00325"></a><span class="lineno">  325</span><span class="comment"> * instead.  Not having to do so definitely simplifies the code, so it is my great hope that the answer is</span></div>
<div class="line"><a id="l00326" name="l00326"></a><span class="lineno">  326</span><span class="comment"> * no, and we can keep using `gcc -O3` and equivalents.  In that case delete this paragraph.</span></div>
<div class="line"><a id="l00327" name="l00327"></a><span class="lineno">  327</span><span class="comment"> * (To be clear: `gcc -O3` means that it ignores `inline` keyword and anything similar, including inlined</span></div>
<div class="line"><a id="l00328" name="l00328"></a><span class="lineno">  328</span><span class="comment"> * method bodies inside `class {}` and `struct {}`.  Instead it determines what to inline based on its own</span></div>
<div class="line"><a id="l00329" name="l00329"></a><span class="lineno">  329</span><span class="comment"> * ideas on what will generate the fastest code (with reasonable code size).  `gcc -O2`, on the other</span></div>
<div class="line"><a id="l00330" name="l00330"></a><span class="lineno">  330</span><span class="comment"> * hand, will mostly inline things explicitly declared as such in code (again, via `inline` or inlining inside</span></div>
<div class="line"><a id="l00331" name="l00331"></a><span class="lineno">  331</span><span class="comment"> * class bodies or other techniques).)  Update: Now using clang (not gcc) with maximum auto-inlining AND FLTO</span></div>
<div class="line"><a id="l00332" name="l00332"></a><span class="lineno">  332</span><span class="comment"> * (link-time optimization will allow inlining across object file boundaries) in at least some platforms.</span></div>
<div class="line"><a id="l00333" name="l00333"></a><span class="lineno">  333</span><span class="comment"> * This should be close to as good as possible.  Update: gcc auto-inlining+FLTO also works.</span></div>
<div class="line"><a id="l00334" name="l00334"></a><span class="lineno">  334</span><span class="comment"> *</span></div>
<div class="line"><a id="l00335" name="l00335"></a><span class="lineno">  335</span><span class="comment"> * @todo One space after period, not two:</span></div>
<div class="line"><a id="l00336" name="l00336"></a><span class="lineno">  336</span><span class="comment"> * For some reason in this project I&#39;ve been following the convention -- in comments and (I think) log</span></div>
<div class="line"><a id="l00337" name="l00337"></a><span class="lineno">  337</span><span class="comment"> * messages -- of two spaces after a sentence-ending punctuator (usually period) before the next sentence&#39;s</span></div>
<div class="line"><a id="l00338" name="l00338"></a><span class="lineno">  338</span><span class="comment"> * first character.  I now regret trying this annoying convention.  Go back to one space. (For the record,</span></div>
<div class="line"><a id="l00339" name="l00339"></a><span class="lineno">  339</span><span class="comment"> * it does look sort of nice, but that&#39;s a matter of opinion, and single space looks fine too... AND doesn&#39;t</span></div>
<div class="line"><a id="l00340" name="l00340"></a><span class="lineno">  340</span><span class="comment"> * confuse various editors&#39; auto-formatting facilityies, among other problem.)</span></div>
<div class="line"><a id="l00341" name="l00341"></a><span class="lineno">  341</span><span class="comment"> *</span></div>
<div class="line"><a id="l00342" name="l00342"></a><span class="lineno">  342</span><span class="comment"> * @todo We use `0` instead of `NULL` or `nullptr` when needing a null pointer; perhaps we should use the latter.</span></div>
<div class="line"><a id="l00343" name="l00343"></a><span class="lineno">  343</span><span class="comment"> * `NULL` is an anachronism from C, so we shouldn&#39;t use it.  `nullptr` is at least no worse than `0`,</span></div>
<div class="line"><a id="l00344" name="l00344"></a><span class="lineno">  344</span><span class="comment"> * however, other than being less concise.  However, the main reason it exists --</span></div>
<div class="line"><a id="l00345" name="l00345"></a><span class="lineno">  345</span><span class="comment"> * to avoid ambiguities in function overloading (e.g., when something could</span></div>
<div class="line"><a id="l00346" name="l00346"></a><span class="lineno">  346</span><span class="comment"> * take either an `int` or a `char*`, `nullptr` would resolve to the latter, while `0` probably unintentionally</span></div>
<div class="line"><a id="l00347" name="l00347"></a><span class="lineno">  347</span><span class="comment"> * to the former) -- is not a situation our style ever invokes, to my knowledge, so using `nullptr` would not</span></div>
<div class="line"><a id="l00348" name="l00348"></a><span class="lineno">  348</span><span class="comment"> * solve any actual problems.  However, it could be argued that using it more readily calls attention to the use</span></div>
<div class="line"><a id="l00349" name="l00349"></a><span class="lineno">  349</span><span class="comment"> * of a pointer, as opposed to an integer, in the particular context at play.  So it&#39;s something to consider</span></div>
<div class="line"><a id="l00350" name="l00350"></a><span class="lineno">  350</span><span class="comment"> * (but, no doubt, the conversion process would be laborious, as there&#39;s no simple search-replace that would</span></div>
<div class="line"><a id="l00351" name="l00351"></a><span class="lineno">  351</span><span class="comment"> * work).</span></div>
<div class="line"><a id="l00352" name="l00352"></a><span class="lineno">  352</span><span class="comment"> *</span></div>
<div class="line"><a id="l00353" name="l00353"></a><span class="lineno">  353</span><span class="comment"> * @todo `= default` for copy constructors and copy operators is now used in a few places; consider spreading</span></div>
<div class="line"><a id="l00354" name="l00354"></a><span class="lineno">  354</span><span class="comment"> * this C++11 feature everywhere it&#39;s being done implicitly due to C++03 rules (good documentation practices suggest</span></div>
<div class="line"><a id="l00355" name="l00355"></a><span class="lineno">  355</span><span class="comment"> * declaring them explicitly but of course leave the implementation to the compiler default, gaining best of both</span></div>
<div class="line"><a id="l00356" name="l00356"></a><span class="lineno">  356</span><span class="comment"> * worlds -- proper class API docs yet maintenance-friendly default body).</span></div>
<div class="line"><a id="l00357" name="l00357"></a><span class="lineno">  357</span><span class="comment"> *</span></div>
<div class="line"><a id="l00358" name="l00358"></a><span class="lineno">  358</span><span class="comment"> * @todo Consider PIMPL and related topics.  Recommend scouring Boost docs, particularly for the smart pointer library,</span></div>
<div class="line"><a id="l00359" name="l00359"></a><span class="lineno">  359</span><span class="comment"> * which discuss how to potentially use smart pointers for easy PIMPLing.  In general, research the state of the art</span></div>
<div class="line"><a id="l00360" name="l00360"></a><span class="lineno">  360</span><span class="comment"> * on the topic of library interface vs. implementation/hiding.</span></div>
<div class="line"><a id="l00361" name="l00361"></a><span class="lineno">  361</span><span class="comment"> *</span></div>
<div class="line"><a id="l00362" name="l00362"></a><span class="lineno">  362</span><span class="comment"> * @todo `std::string_view` is a way to pass things around similarly to `const std::string&amp;` without requiring</span></div>
<div class="line"><a id="l00363" name="l00363"></a><span class="lineno">  363</span><span class="comment"> * that a `string` be created just for that purpose; it has a highly similar API but can be constructed from any</span></div>
<div class="line"><a id="l00364" name="l00364"></a><span class="lineno">  364</span><span class="comment"> * character sequence in memory and internally stores nothing more than a pointer and length; we should use it wherever</span></div>
<div class="line"><a id="l00365" name="l00365"></a><span class="lineno">  365</span><span class="comment"> * possible (within reason) instead of `const std::string&amp;`.  Much code now uses `String_view`; the remaining to-do</span></div>
<div class="line"><a id="l00366" name="l00366"></a><span class="lineno">  366</span><span class="comment"> * is: scour the rest of the code for possible `const string&amp;`s to convert and indeed convert those to</span></div>
<div class="line"><a id="l00367" name="l00367"></a><span class="lineno">  367</span><span class="comment"> * util::String_view.</span></div>
<div class="line"><a id="l00368" name="l00368"></a><span class="lineno">  368</span><span class="comment"> *</span></div>
<div class="line"><a id="l00369" name="l00369"></a><span class="lineno">  369</span><span class="comment"> * @todo Return-by-copy binary operators of the form `T operatorBLAH(const T&amp; x1, const Some_type&amp; x2)` should be</span></div>
<div class="line"><a id="l00370" name="l00370"></a><span class="lineno">  370</span><span class="comment"> * written as free functions instead of `T` members.  I don&#39;t recall at this point why, but this tends to be recommended</span></div>
<div class="line"><a id="l00371" name="l00371"></a><span class="lineno">  371</span><span class="comment"> * and done in STL and Boost.  Maybe check the Meyer Effective C++ book on the theory; and if it makes sense find all</span></div>
<div class="line"><a id="l00372" name="l00372"></a><span class="lineno">  372</span><span class="comment"> * such operators written as members and change them to be free functions.  Should this be avoided if it requires</span></div>
<div class="line"><a id="l00373" name="l00373"></a><span class="lineno">  373</span><span class="comment"> * `friend` though?  Lastly, for Doxygen, use the `relatesalso T` command to link the free function to the class `T`</span></div>
<div class="line"><a id="l00374" name="l00374"></a><span class="lineno">  374</span><span class="comment"> * in the documentation.</span></div>
<div class="line"><a id="l00375" name="l00375"></a><span class="lineno">  375</span><span class="comment"> *</span></div>
<div class="line"><a id="l00376" name="l00376"></a><span class="lineno">  376</span><span class="comment"> * @todo In many (most) cases we pass `shared_ptr`s (and their aliases) by value when it would be more performant to</span></div>
<div class="line"><a id="l00377" name="l00377"></a><span class="lineno">  377</span><span class="comment"> * do so by `const` reference; at times possibly better to pass by raw pointer.  Scott Meyer/Herb Sutter have opined</span></div>
<div class="line"><a id="l00378" name="l00378"></a><span class="lineno">  378</span><span class="comment"> * on this to basically indicate that (1) it is often best to use a raw pointer, unless actual copying/ownership status</span></div>
<div class="line"><a id="l00379" name="l00379"></a><span class="lineno">  379</span><span class="comment"> * is expected; but failing that (2) it is often best to use a `const&amp;` when safe; and failing that passing by</span></div>
<div class="line"><a id="l00380" name="l00380"></a><span class="lineno">  380</span><span class="comment"> * value is fine.  This need not be a dogmatic change, but we should be more mindful than simply always passing by</span></div>
<div class="line"><a id="l00381" name="l00381"></a><span class="lineno">  381</span><span class="comment"> * value.  When searching for instances to potentially change, check for `shared_ptr`, `Ptr`, and `_ptr` tokens.</span></div>
<div class="line"><a id="l00382" name="l00382"></a><span class="lineno">  382</span><span class="comment"> */</span></div>
<div class="line"><a id="l00383" name="l00383"></a><span class="lineno">  383</span><span class="keyword">namespace </span><a class="code hl_namespace" href="namespaceflow.html">flow</a></div>
<div class="line"><a id="l00384" name="l00384"></a><span class="lineno">  384</span>{</div>
<div class="line"><a id="l00385" name="l00385"></a><span class="lineno">  385</span> </div>
<div class="line"><a id="l00386" name="l00386"></a><span class="lineno">  386</span><span class="comment">// Types.  They&#39;re outside of `namespace ::flow::util` for brevity due to their frequent use.</span></div>
<div class="line"><a id="l00387" name="l00387"></a><span class="lineno">  387</span> </div>
<div class="line"><a id="l00388" name="l00388"></a><span class="lineno">  388</span><span class="comment">// Integer short-hands and specific-bit-width types.</span></div>
<div class="line"><a id="l00389" name="l00389"></a><span class="lineno">  389</span><span class="comment"></span> </div>
<div class="line"><a id="l00390" name="l00390"></a><span class="lineno">  390</span><span class="comment">/// Byte.  Best way to represent a byte of binary data.  This is 8 bits on all modern systems.</span></div>
<div class="line"><a id="l00391" name="l00391"></a><span class="lineno"><a class="line" href="namespaceflow.html#ae02da22c4a101eaab447511c905e4f32">  391</a></span><span class="comment"></span><span class="keyword">using </span><a class="code hl_typedef" href="namespaceflow.html#ae02da22c4a101eaab447511c905e4f32">uint8_t</a> = <span class="keywordtype">unsigned</span> char;<span class="comment"></span></div>
<div class="line"><a id="l00392" name="l00392"></a><span class="lineno">  392</span><span class="comment">/// Signed byte.  Prefer to use `uint8_t` when representing binary data.  This is 8 bits on all modern systems.</span></div>
<div class="line"><a id="l00393" name="l00393"></a><span class="lineno"><a class="line" href="namespaceflow.html#a96b8a241b21c907e96cb91f4bf868446">  393</a></span><span class="comment"></span><span class="keyword">using </span><a class="code hl_typedef" href="namespaceflow.html#a96b8a241b21c907e96cb91f4bf868446">int8_t</a> = <span class="keywordtype">signed</span> char;</div>
<div class="line"><a id="l00394" name="l00394"></a><span class="lineno">  394</span> </div>
<div class="line"><a id="l00395" name="l00395"></a><span class="lineno">  395</span><span class="comment">// Time-related short-hands.</span></div>
<div class="line"><a id="l00396" name="l00396"></a><span class="lineno">  396</span><span class="comment"></span> </div>
<div class="line"><a id="l00397" name="l00397"></a><span class="lineno">  397</span><span class="comment">/**</span></div>
<div class="line"><a id="l00398" name="l00398"></a><span class="lineno">  398</span><span class="comment"> * Clock used for delicate time measurements, such that the `now()` method gets the current time</span></div>
<div class="line"><a id="l00399" name="l00399"></a><span class="lineno">  399</span><span class="comment"> * relative to some unknown but constant epoch (reference point).  Used to measure durations of</span></div>
<div class="line"><a id="l00400" name="l00400"></a><span class="lineno">  400</span><span class="comment"> * things.  It has the following properties:</span></div>
<div class="line"><a id="l00401" name="l00401"></a><span class="lineno">  401</span><span class="comment"> *</span></div>
<div class="line"><a id="l00402" name="l00402"></a><span class="lineno">  402</span><span class="comment"> *   - Steady: time cannot go backwards (e.g., via user time change, NTP); time values increment at</span></div>
<div class="line"><a id="l00403" name="l00403"></a><span class="lineno">  403</span><span class="comment"> *     a rate proportional to real time (no leap seconds for example).</span></div>
<div class="line"><a id="l00404" name="l00404"></a><span class="lineno">  404</span><span class="comment"> *   - High-resolution: the increments of time at which the clock runs are as small as supported</span></div>
<div class="line"><a id="l00405" name="l00405"></a><span class="lineno">  405</span><span class="comment"> *     by the OS+hardware.  This should be at most a handful of microseconds in practice.</span></div>
<div class="line"><a id="l00406" name="l00406"></a><span class="lineno">  406</span><span class="comment"> *</span></div>
<div class="line"><a id="l00407" name="l00407"></a><span class="lineno">  407</span><span class="comment"> * So basically it&#39;s a precise clock with no surprises (which is more than can be said for stuff people</span></div>
<div class="line"><a id="l00408" name="l00408"></a><span class="lineno">  408</span><span class="comment"> * tend to be forced to use, like `gettimeofday()`).</span></div>
<div class="line"><a id="l00409" name="l00409"></a><span class="lineno">  409</span><span class="comment"> */</span></div>
<div class="line"><a id="l00410" name="l00410"></a><span class="lineno"><a class="line" href="namespaceflow.html#a8f2e48761f9ca3ffcaa29872078bbf00">  410</a></span><span class="keyword">using </span><a class="code hl_typedef" href="namespaceflow.html#a8f2e48761f9ca3ffcaa29872078bbf00">Fine_clock</a> = boost::chrono::high_resolution_clock;</div>
<div class="line"><a id="l00411" name="l00411"></a><span class="lineno">  411</span><span class="comment"></span> </div>
<div class="line"><a id="l00412" name="l00412"></a><span class="lineno">  412</span><span class="comment">/// A high-res time point as returned by `Fine_clock::now()` and suitable for precise time math in general.</span></div>
<div class="line"><a id="l00413" name="l00413"></a><span class="lineno"><a class="line" href="namespaceflow.html#a9d9cc2eeb10d398cff5591d446b763b8">  413</a></span><span class="comment"></span><span class="keyword">using </span><a class="code hl_typedef" href="namespaceflow.html#a9d9cc2eeb10d398cff5591d446b763b8">Fine_time_pt</a> = Fine_clock::time_point;</div>
<div class="line"><a id="l00414" name="l00414"></a><span class="lineno">  414</span><span class="comment"></span> </div>
<div class="line"><a id="l00415" name="l00415"></a><span class="lineno">  415</span><span class="comment">/// A high-res time duration as computed from two `Fine_time_pt`s.</span></div>
<div class="line"><a id="l00416" name="l00416"></a><span class="lineno"><a class="line" href="namespaceflow.html#a48799f1263cdeedec125be51a3db2b79">  416</a></span><span class="comment"></span><span class="keyword">using </span><a class="code hl_typedef" href="namespaceflow.html#a48799f1263cdeedec125be51a3db2b79">Fine_duration</a> = Fine_clock::duration;</div>
<div class="line"><a id="l00417" name="l00417"></a><span class="lineno">  417</span><span class="comment"></span> </div>
<div class="line"><a id="l00418" name="l00418"></a><span class="lineno">  418</span><span class="comment">/**</span></div>
<div class="line"><a id="l00419" name="l00419"></a><span class="lineno">  419</span><span class="comment"> * Short-hand for a boost.system error code (which basically encapsulates an integer/`enum` error</span></div>
<div class="line"><a id="l00420" name="l00420"></a><span class="lineno">  420</span><span class="comment"> * code and a pointer through which to obtain a statically stored message string); this is how Flow modules</span></div>
<div class="line"><a id="l00421" name="l00421"></a><span class="lineno">  421</span><span class="comment"> * report errors to the user; and we humbly recommended all C++ code use the same techniques.</span></div>
<div class="line"><a id="l00422" name="l00422"></a><span class="lineno">  422</span><span class="comment"> *</span></div>
<div class="line"><a id="l00423" name="l00423"></a><span class="lineno">  423</span><span class="comment"> * @note It is not inside flow::error namespace due to its (`Error_code`&#39;s) ubiquity.</span></div>
<div class="line"><a id="l00424" name="l00424"></a><span class="lineno">  424</span><span class="comment"> *       Very few other symbols should follow suit.  We may decide to move it there after all.</span></div>
<div class="line"><a id="l00425" name="l00425"></a><span class="lineno">  425</span><span class="comment"> *</span></div>
<div class="line"><a id="l00426" name="l00426"></a><span class="lineno">  426</span><span class="comment"> * ### Basic error-emitting API semantics ###</span></div>
<div class="line"><a id="l00427" name="l00427"></a><span class="lineno">  427</span><span class="comment"> *</span></div>
<div class="line"><a id="l00428" name="l00428"></a><span class="lineno">  428</span><span class="comment"> * All error-reporting Flow APIs follow the following pattern of error reporting semantics.</span></div>
<div class="line"><a id="l00429" name="l00429"></a><span class="lineno">  429</span><span class="comment"> * Each API looks something like:</span></div>
<div class="line"><a id="l00430" name="l00430"></a><span class="lineno">  430</span><span class="comment"> *</span></div>
<div class="line"><a id="l00431" name="l00431"></a><span class="lineno">  431</span><span class="comment"> *   ~~~</span></div>
<div class="line"><a id="l00432" name="l00432"></a><span class="lineno">  432</span><span class="comment"> *   return_type Some_class::some_op(..., flow::Error_code* err_code)</span></div>
<div class="line"><a id="l00433" name="l00433"></a><span class="lineno">  433</span><span class="comment"> *   ~~~</span></div>
<div class="line"><a id="l00434" name="l00434"></a><span class="lineno">  434</span><span class="comment"> *</span></div>
<div class="line"><a id="l00435" name="l00435"></a><span class="lineno">  435</span><span class="comment"> * Then, there are two possibilities.  If you pass in non-null `err_code`, then after return `*err_code` is</span></div>
<div class="line"><a id="l00436" name="l00436"></a><span class="lineno">  436</span><span class="comment"> * success (falsy) or a truthy `enum`-like value, representing a specific error.  If, instead, you pass in null,</span></div>
<div class="line"><a id="l00437" name="l00437"></a><span class="lineno">  437</span><span class="comment"> * then a flow::error::Runtime_error() `exc` is thrown if and only if `*err_code` would have been set to truthy value</span></div>
<div class="line"><a id="l00438" name="l00438"></a><span class="lineno">  438</span><span class="comment"> * `e_c` had a non-null `err_code` been passed in.  If such an exception is thrown, `Error_code e_c` is</span></div>
<div class="line"><a id="l00439" name="l00439"></a><span class="lineno">  439</span><span class="comment"> * encapsulated in exception object `exc`.  If and only if no exception is thrown, there was no error (`*err_code` would</span></div>
<div class="line"><a id="l00440" name="l00440"></a><span class="lineno">  440</span><span class="comment"> * have been falsy).</span></div>
<div class="line"><a id="l00441" name="l00441"></a><span class="lineno">  441</span><span class="comment"> *</span></div>
<div class="line"><a id="l00442" name="l00442"></a><span class="lineno">  442</span><span class="comment"> * Thus, you get the best of both worlds: you can get the simplicity and performance</span></div>
<div class="line"><a id="l00443" name="l00443"></a><span class="lineno">  443</span><span class="comment"> * of an error code; or the various features of an exception (including access to the error code via</span></div>
<div class="line"><a id="l00444" name="l00444"></a><span class="lineno">  444</span><span class="comment"> * `exc.code()` if desired), with the same API signature.  (boost.asio</span></div>
<div class="line"><a id="l00445" name="l00445"></a><span class="lineno">  445</span><span class="comment"> * follows a similar concept, though it requires two API signatures for each operation, one without</span></div>
<div class="line"><a id="l00446" name="l00446"></a><span class="lineno">  446</span><span class="comment"> * an `Error_code` argument, and one with non-`const` `Error_code&amp;` out-arg.  The above convention is more compact;</span></div>
<div class="line"><a id="l00447" name="l00447"></a><span class="lineno">  447</span><span class="comment"> * plus we provide certain tools to reduce boiler-plate in connection with this.)</span></div>
<div class="line"><a id="l00448" name="l00448"></a><span class="lineno">  448</span><span class="comment"> *</span></div>
<div class="line"><a id="l00449" name="l00449"></a><span class="lineno">  449</span><span class="comment"> * ### Intro to `Error_code`, a/k/a boost.system `error_code` ###</span></div>
<div class="line"><a id="l00450" name="l00450"></a><span class="lineno">  450</span><span class="comment"> * (I am restating boost.system documentation here, but that particular set of docs is notoriously</span></div>
<div class="line"><a id="l00451" name="l00451"></a><span class="lineno">  451</span><span class="comment"> * formal-but-reader-unfriendly.)</span></div>
<div class="line"><a id="l00452" name="l00452"></a><span class="lineno">  452</span><span class="comment"> *</span></div>
<div class="line"><a id="l00453" name="l00453"></a><span class="lineno">  453</span><span class="comment"> * A truthy `Error_code` is a very lightweight -- `errno`-like in that regard -- value indicating</span></div>
<div class="line"><a id="l00454" name="l00454"></a><span class="lineno">  454</span><span class="comment"> * the error that occurred.  It stores an `int` code and a &quot;category&quot; pointer (basically, thing specifying to what code</span></div>
<div class="line"><a id="l00455" name="l00455"></a><span class="lineno">  455</span><span class="comment"> * set this belongs).  The `int` is to be converted from the error code set of choice, whereas the category pointer is</span></div>
<div class="line"><a id="l00456" name="l00456"></a><span class="lineno">  456</span><span class="comment"> * internally magically determined based on the type of the error code value being converted to `Error_code`.</span></div>
<div class="line"><a id="l00457" name="l00457"></a><span class="lineno">  457</span><span class="comment"> *</span></div>
<div class="line"><a id="l00458" name="l00458"></a><span class="lineno">  458</span><span class="comment"> * An `Error_code` itself can be serialized into `ostream`s (and thus `string`s via `lexical_cast`, etc.) easily for</span></div>
<div class="line"><a id="l00459" name="l00459"></a><span class="lineno">  459</span><span class="comment"> * logging purposes/etc.  You can access both the numeric code and a human explanation of the error.</span></div>
<div class="line"><a id="l00460" name="l00460"></a><span class="lineno">  460</span><span class="comment"> * Any and all error code sets are supported by this boost.system type.  POSIX `errno`s are one possible set of codes;</span></div>
<div class="line"><a id="l00461" name="l00461"></a><span class="lineno">  461</span><span class="comment"> * boost.asio has its own code set; and other modules in `flow` may introduce their own code sets.  All are compatible</span></div>
<div class="line"><a id="l00462" name="l00462"></a><span class="lineno">  462</span><span class="comment"> * for equality/assignment/etc. with this general `Error_code` type.</span></div>
<div class="line"><a id="l00463" name="l00463"></a><span class="lineno">  463</span><span class="comment"> *</span></div>
<div class="line"><a id="l00464" name="l00464"></a><span class="lineno">  464</span><span class="comment"> * As stated, all error-emitting Flow public APIs (regardless of module) use the above-described error-reporting</span></div>
<div class="line"><a id="l00465" name="l00465"></a><span class="lineno">  465</span><span class="comment"> * conventions.  In addition, we humbly recommend Flow *user* code adopt the same battle-tested conventions.  However</span></div>
<div class="line"><a id="l00466" name="l00466"></a><span class="lineno">  466</span><span class="comment"> * that is absolutely not required and is entirely independent of the fact that Flow modules use them.  Do note this</span></div>
<div class="line"><a id="l00467" name="l00467"></a><span class="lineno">  467</span><span class="comment"> * convention is battle-tested in boost.asio as well; though Flow&#39;s version is more compact; by using a pointer (which</span></div>
<div class="line"><a id="l00468" name="l00468"></a><span class="lineno">  468</span><span class="comment"> * can be null) instead of a reference it cuts the number of error-emitting API functions in half.</span></div>
<div class="line"><a id="l00469" name="l00469"></a><span class="lineno">  469</span><span class="comment"> *</span></div>
<div class="line"><a id="l00470" name="l00470"></a><span class="lineno">  470</span><span class="comment"> * For each function (including each publicly exported error-reporting function within Flow) that indeed agrees to</span></div>
<div class="line"><a id="l00471" name="l00471"></a><span class="lineno">  471</span><span class="comment"> * use the above convention, follow these instructions:</span></div>
<div class="line"><a id="l00472" name="l00472"></a><span class="lineno">  472</span><span class="comment"> *</span></div>
<div class="line"><a id="l00473" name="l00473"></a><span class="lineno">  473</span><span class="comment"> * To reduce boiler-plate, within reason, it is incumbent on each error-reporting method to use the following</span></div>
<div class="line"><a id="l00474" name="l00474"></a><span class="lineno">  474</span><span class="comment"> * technique:</span></div>
<div class="line"><a id="l00475" name="l00475"></a><span class="lineno">  475</span><span class="comment"> *</span></div>
<div class="line"><a id="l00476" name="l00476"></a><span class="lineno">  476</span><span class="comment"> * - The method signature should be similar to the above (including naming it `err_code`) and use the above semantics.</span></div>
<div class="line"><a id="l00477" name="l00477"></a><span class="lineno">  477</span><span class="comment"> *   - Use FLOW_ERROR_EXEC_AND_THROW_ON_ERROR() (and/or nearby similar utilities in flow/error/error.hpp) for minimal</span></div>
<div class="line"><a id="l00478" name="l00478"></a><span class="lineno">  478</span><span class="comment"> *     boiler-plate that implements these semantics.  See doc header for that macro for details.</span></div>
<div class="line"><a id="l00479" name="l00479"></a><span class="lineno">  479</span><span class="comment"> * - You may or may not indicate the lack or presence of an error condition via some additional non-exception technique</span></div>
<div class="line"><a id="l00480" name="l00480"></a><span class="lineno">  480</span><span class="comment"> *   such as a `bool` return value.</span></div>
<div class="line"><a id="l00481" name="l00481"></a><span class="lineno">  481</span><span class="comment"> * - The error behavior documentation should be *confined entirely* to the documentation of `err_code` parameter, so</span></div>
<div class="line"><a id="l00482" name="l00482"></a><span class="lineno">  482</span><span class="comment"> *   that the above semantics need not be repetitively restated a million times.</span></div>
<div class="line"><a id="l00483" name="l00483"></a><span class="lineno">  483</span><span class="comment"> *   The text of the parameter&#39;s doc should usually be as follows (you may copy/paste to start).  In this example</span></div>
<div class="line"><a id="l00484" name="l00484"></a><span class="lineno">  484</span><span class="comment"> *   the function returns codes from the `net_flow::error::Code` code set `enum`; but please substitute your code set of</span></div>
<div class="line"><a id="l00485" name="l00485"></a><span class="lineno">  485</span><span class="comment"> *   choice (again; `errno` and boost.asio error codes are 2 possible other examples of code sets).  Here we go:</span></div>
<div class="line"><a id="l00486" name="l00486"></a><span class="lineno">  486</span><span class="comment"> *</span></div>
<div class="line"><a id="l00487" name="l00487"></a><span class="lineno">  487</span><span class="comment"> *   ~~~</span></div>
<div class="line"><a id="l00488" name="l00488"></a><span class="lineno">  488</span><span class="comment"> *   // param err_code</span></div>
<div class="line"><a id="l00489" name="l00489"></a><span class="lineno">  489</span><span class="comment"> *   //       See flow::Error_code docs for error reporting semantics.  net_flow::error::Code generated:</span></div>
<div class="line"><a id="l00490" name="l00490"></a><span class="lineno">  490</span><span class="comment"> *   //       net_flow::error::Code::S_(...) (optional comment), ...more... , net_flow::error::Code::S_(...)</span></div>
<div class="line"><a id="l00491" name="l00491"></a><span class="lineno">  491</span><span class="comment"> *   //       (optional comment).</span></div>
<div class="line"><a id="l00492" name="l00492"></a><span class="lineno">  492</span><span class="comment"> *   ~~~</span></div>
<div class="line"><a id="l00493" name="l00493"></a><span class="lineno">  493</span><span class="comment"> *</span></div>
<div class="line"><a id="l00494" name="l00494"></a><span class="lineno">  494</span><span class="comment"> * @see The doc header (and code inside) `namespace` flow::net_flow::error is a good primer showing how to create</span></div>
<div class="line"><a id="l00495" name="l00495"></a><span class="lineno">  495</span><span class="comment"> *      an `Error_code`-compatible set of error codes.  This is easier to understand than boost.asio&#39;s counterpart</span></div>
<div class="line"><a id="l00496" name="l00496"></a><span class="lineno">  496</span><span class="comment"> *      for example.</span></div>
<div class="line"><a id="l00497" name="l00497"></a><span class="lineno">  497</span><span class="comment"> *</span></div>
<div class="line"><a id="l00498" name="l00498"></a><span class="lineno">  498</span><span class="comment"> * @note boost.system at some point -- I (ygoldfel) am fairly sure after I designed the above ages ago -- introduced</span></div>
<div class="line"><a id="l00499" name="l00499"></a><span class="lineno">  499</span><span class="comment"> *       an alternate idiom for passing an #Error_code out-arg that is to be ignored in favor of throwing an exception</span></div>
<div class="line"><a id="l00500" name="l00500"></a><span class="lineno">  500</span><span class="comment"> *       if omitted.  We use the idiom: `Error_code*` out-arg, throw if null.  They, instead propose:</span></div>
<div class="line"><a id="l00501" name="l00501"></a><span class="lineno">  501</span><span class="comment"> *       `Error_code&amp;` out-arg, throw if it equals `boost::system::throws()`.  That&#39;s great, too, but actually our</span></div>
<div class="line"><a id="l00502" name="l00502"></a><span class="lineno">  502</span><span class="comment"> *       idiom hews to another bit of the Flow coding style/guide, wherein out-args should be pointers, not</span></div>
<div class="line"><a id="l00503" name="l00503"></a><span class="lineno">  503</span><span class="comment"> *       non-`const` references -- and is otherwise very similar.  So it&#39;s fine.  Note that their idiom vs. ours =</span></div>
<div class="line"><a id="l00504" name="l00504"></a><span class="lineno">  504</span><span class="comment"> *       orthogonal to the main difficulty which is the boiler-plate associated with actually throwing vs. non-throwing;</span></div>
<div class="line"><a id="l00505" name="l00505"></a><span class="lineno">  505</span><span class="comment"> *       this would be required regardless of the API idiom chosen.  The above (involving</span></div>
<div class="line"><a id="l00506" name="l00506"></a><span class="lineno">  506</span><span class="comment"> *       FLOW_ERROR_EXEC_AND_THROW_ON_ERROR(), etc.) is really the main crux of it.</span></div>
<div class="line"><a id="l00507" name="l00507"></a><span class="lineno">  507</span><span class="comment"> */</span></div>
<div class="line"><a id="l00508" name="l00508"></a><span class="lineno"><a class="line" href="namespaceflow.html#a29eaaa9d0fac4ce87d8b969222dbed09">  508</a></span><span class="keyword">using </span><a class="code hl_typedef" href="namespaceflow.html#a29eaaa9d0fac4ce87d8b969222dbed09">Error_code</a> = boost::system::error_code;</div>
<div class="line"><a id="l00509" name="l00509"></a><span class="lineno">  509</span> </div>
<div class="line"><a id="l00510" name="l00510"></a><span class="lineno">  510</span><span class="comment">// See just below.</span></div>
<div class="line"><a id="l00511" name="l00511"></a><span class="lineno">  511</span><span class="keyword">template</span>&lt;<span class="keyword">typename</span> Signature&gt;</div>
<div class="line"><a id="l00512" name="l00512"></a><span class="lineno"><a class="line" href="classflow_1_1Function.html">  512</a></span><span class="keyword">class </span><a class="code hl_class" href="classflow_1_1Function.html">Function</a>;</div>
<div class="line"><a id="l00513" name="l00513"></a><span class="lineno">  513</span><span class="comment"></span> </div>
<div class="line"><a id="l00514" name="l00514"></a><span class="lineno">  514</span><span class="comment">/**</span></div>
<div class="line"><a id="l00515" name="l00515"></a><span class="lineno">  515</span><span class="comment"> * Intended as the polymorphic function wrapper of choice for Flow, internally and externally; to be used</span></div>
<div class="line"><a id="l00516" name="l00516"></a><span class="lineno">  516</span><span class="comment"> * instead of `std::function` or `boost::function`.  Due to ubiquitous use of such function-object wrappers,</span></div>
<div class="line"><a id="l00517" name="l00517"></a><span class="lineno">  517</span><span class="comment"> * this is one of the very few direct non-`namespace` members of the outer namespace `::flow`.</span></div>
<div class="line"><a id="l00518" name="l00518"></a><span class="lineno">  518</span><span class="comment"> *</span></div>
<div class="line"><a id="l00519" name="l00519"></a><span class="lineno">  519</span><span class="comment"> * In reality it *is* `std::function`, with a couple of added APIs (no data) to make it more similar to</span></div>
<div class="line"><a id="l00520" name="l00520"></a><span class="lineno">  520</span><span class="comment"> * `boost::function` API-wise.</span></div>
<div class="line"><a id="l00521" name="l00521"></a><span class="lineno">  521</span><span class="comment"> *</span></div>
<div class="line"><a id="l00522" name="l00522"></a><span class="lineno">  522</span><span class="comment"> * ### Rationale ###</span></div>
<div class="line"><a id="l00523" name="l00523"></a><span class="lineno">  523</span><span class="comment"> * By far the main reason this exists is: I (ygoldfel) conducted an investigation in 2022, with a not-too-old gcc</span></div>
<div class="line"><a id="l00524" name="l00524"></a><span class="lineno">  524</span><span class="comment"> * in Linux, in C++17 mode, with Boost 1.78 (but built seemingly in C++03-supporting config) about the</span></div>
<div class="line"><a id="l00525" name="l00525"></a><span class="lineno">  525</span><span class="comment"> * performance behavior of lambdas objects and `boost::function&lt;&gt;` and `std::function&lt;&gt;` wrappers thereof.</span></div>
<div class="line"><a id="l00526" name="l00526"></a><span class="lineno">  526</span><span class="comment"> * I noticed these things:</span></div>
<div class="line"><a id="l00527" name="l00527"></a><span class="lineno">  527</span><span class="comment"> *   - Say one constructs a `boost::function` from a lambda that has 1 or more by-value captures `[x = std::move(x)]`,</span></div>
<div class="line"><a id="l00528" name="l00528"></a><span class="lineno">  528</span><span class="comment"> *     with those captures&#39; types having move ctors different and faster than copy ctors.  I found that this not only</span></div>
<div class="line"><a id="l00529" name="l00529"></a><span class="lineno">  529</span><span class="comment"> *     *copies* each of those captures (invokes their copy ctors), but it even does so several times!</span></div>
<div class="line"><a id="l00530" name="l00530"></a><span class="lineno">  530</span><span class="comment"> *     - However, constructing an `std::function` identically never invokes copy ctors -- only move ctors --</span></div>
<div class="line"><a id="l00531" name="l00531"></a><span class="lineno">  531</span><span class="comment"> *       and fewer times at that.</span></div>
<div class="line"><a id="l00532" name="l00532"></a><span class="lineno">  532</span><span class="comment"> *   - Say one constructs a `boost::function` from a lambda that has 1 or more by-value captures `[x = std::move(x)]`,</span></div>
<div class="line"><a id="l00533" name="l00533"></a><span class="lineno">  533</span><span class="comment"> *     with those captures&#39; types having move ctors but `= delete`d copy ctors.  I.e., say at least 1 capture is</span></div>
<div class="line"><a id="l00534" name="l00534"></a><span class="lineno">  534</span><span class="comment"> *     movable but not copyable; `unique_ptr` being a classic and practical example.  Well: This does not compile;</span></div>
<div class="line"><a id="l00535" name="l00535"></a><span class="lineno">  535</span><span class="comment"> *     gcc complains `boost::function` needs `unique_ptr` to have a copy ctor, but it is `delete`d.</span></div>
<div class="line"><a id="l00536" name="l00536"></a><span class="lineno">  536</span><span class="comment"> *     In the case of `unique_ptr`, one can do `[x = shared_ptr(std::move(x))]` to get it work, though it&#39;s a bit</span></div>
<div class="line"><a id="l00537" name="l00537"></a><span class="lineno">  537</span><span class="comment"> *     more code, reduces perf by adding ref-counting, and reduces smart-ptr safety inside the lambda body.</span></div>
<div class="line"><a id="l00538" name="l00538"></a><span class="lineno">  538</span><span class="comment"> *     - However, constructing an `std::function` identically compiles and works fine.</span></div>
<div class="line"><a id="l00539" name="l00539"></a><span class="lineno">  539</span><span class="comment"> *</span></div>
<div class="line"><a id="l00540" name="l00540"></a><span class="lineno">  540</span><span class="comment"> * So, long story short, at least in that environment, `std::function` is just plain faster than `boost::function`,</span></div>
<div class="line"><a id="l00541" name="l00541"></a><span class="lineno">  541</span><span class="comment"> * avoiding copying of captures; and it&#39;s easier to use with movable-not-copyable capture types.</span></div>
<div class="line"><a id="l00542" name="l00542"></a><span class="lineno">  542</span><span class="comment"> *</span></div>
<div class="line"><a id="l00543" name="l00543"></a><span class="lineno">  543</span><span class="comment"> * So we could have just done circa `using Function = std::function;`.  Why the subclass?  Answer: `std::function`</span></div>
<div class="line"><a id="l00544" name="l00544"></a><span class="lineno">  544</span><span class="comment"> * lacks a couple of commonly used `boost::function` APIs that code tends to rely on (in the past we used</span></div>
<div class="line"><a id="l00545" name="l00545"></a><span class="lineno">  545</span><span class="comment"> * `boost::function`).  These are empty() and clear() as of this writing.  See their doc headers (nothing amazing).</span></div>
<div class="line"><a id="l00546" name="l00546"></a><span class="lineno">  546</span><span class="comment"> *</span></div>
<div class="line"><a id="l00547" name="l00547"></a><span class="lineno">  547</span><span class="comment"> * Lastly: In the aforementioned environment, possibly because of having to support C++03 (which lacked</span></div>
<div class="line"><a id="l00548" name="l00548"></a><span class="lineno">  548</span><span class="comment"> * param packs) -- unlike `std::function` which was introduced in C++11 to begin with (and</span></div>
<div class="line"><a id="l00549" name="l00549"></a><span class="lineno">  549</span><span class="comment"> * probably conceptually based on `boost::function`) -- `boost::function`</span></div>
<div class="line"><a id="l00550" name="l00550"></a><span class="lineno">  550</span><span class="comment"> * supports up to 10 args and does not compile when used with 11+ args.  `std::function`, and therefore Function,</span></div>
<div class="line"><a id="l00551" name="l00551"></a><span class="lineno">  551</span><span class="comment"> * lacks this limitation.  It can be used with any number of args.</span></div>
<div class="line"><a id="l00552" name="l00552"></a><span class="lineno">  552</span><span class="comment"> *</span></div>
<div class="line"><a id="l00553" name="l00553"></a><span class="lineno">  553</span><span class="comment"> * @tparam Result</span></div>
<div class="line"><a id="l00554" name="l00554"></a><span class="lineno">  554</span><span class="comment"> *         See `std::function`.</span></div>
<div class="line"><a id="l00555" name="l00555"></a><span class="lineno">  555</span><span class="comment"> * @tparam Args</span></div>
<div class="line"><a id="l00556" name="l00556"></a><span class="lineno">  556</span><span class="comment"> *         See `std::function`.</span></div>
<div class="line"><a id="l00557" name="l00557"></a><span class="lineno">  557</span><span class="comment"> */</span></div>
<div class="line"><a id="l00558" name="l00558"></a><span class="lineno">  558</span><span class="keyword">template</span>&lt;<span class="keyword">typename</span> Result, <span class="keyword">typename</span>... Args&gt;</div>
<div class="line"><a id="l00559" name="l00559"></a><span class="lineno"><a class="line" href="classflow_1_1Function_3_01Result_07Args_8_8_8_08_4.html">  559</a></span><span class="keyword">class </span><a class="code hl_class" href="classflow_1_1Function.html">Function</a>&lt;Result (Args...)&gt; :</div>
<div class="line"><a id="l00560" name="l00560"></a><span class="lineno">  560</span>  <span class="keyword">public</span> std::function&lt;Result (Args...)&gt;</div>
<div class="line"><a id="l00561" name="l00561"></a><span class="lineno">  561</span>{</div>
<div class="line"><a id="l00562" name="l00562"></a><span class="lineno">  562</span><span class="keyword">public</span>:</div>
<div class="line"><a id="l00563" name="l00563"></a><span class="lineno">  563</span>  <span class="comment">// Types.</span></div>
<div class="line"><a id="l00564" name="l00564"></a><span class="lineno">  564</span><span class="comment"></span> </div>
<div class="line"><a id="l00565" name="l00565"></a><span class="lineno">  565</span><span class="comment">  /// Short-hand for the base.  We add no data of our own in this subclass, just a handful of APIs.</span></div>
<div class="line"><a id="l00566" name="l00566"></a><span class="lineno"><a class="line" href="classflow_1_1Function_3_01Result_07Args_8_8_8_08_4.html#ac9d820d29d397987a6a97469f39e367e">  566</a></span><span class="comment"></span>  <span class="keyword">using </span><a class="code hl_typedef" href="classflow_1_1Function_3_01Result_07Args_8_8_8_08_4.html#ac9d820d29d397987a6a97469f39e367e">Function_base</a> = std::function&lt;Result (Args...)&gt;;</div>
<div class="line"><a id="l00567" name="l00567"></a><span class="lineno">  567</span> </div>
<div class="line"><a id="l00568" name="l00568"></a><span class="lineno">  568</span>  <span class="comment">// Ctors/destructor.</span></div>
<div class="line"><a id="l00569" name="l00569"></a><span class="lineno">  569</span><span class="comment"></span> </div>
<div class="line"><a id="l00570" name="l00570"></a><span class="lineno">  570</span><span class="comment">  /// Inherit all the constructors from #Function_base.  Add none of our own.</span></div>
<div class="line"><a id="l00571" name="l00571"></a><span class="lineno">  571</span><span class="comment"></span>  <span class="keyword">using </span>Function_base::Function_base;</div>
<div class="line"><a id="l00572" name="l00572"></a><span class="lineno">  572</span> </div>
<div class="line"><a id="l00573" name="l00573"></a><span class="lineno">  573</span>  <span class="comment">// Methods.</span></div>
<div class="line"><a id="l00574" name="l00574"></a><span class="lineno">  574</span><span class="comment"></span> </div>
<div class="line"><a id="l00575" name="l00575"></a><span class="lineno">  575</span><span class="comment">  /**</span></div>
<div class="line"><a id="l00576" name="l00576"></a><span class="lineno">  576</span><span class="comment">   * Returns `!bool(*this)`; i.e., `true` if and only if `*this` has no target.</span></div>
<div class="line"><a id="l00577" name="l00577"></a><span class="lineno">  577</span><span class="comment">   *</span></div>
<div class="line"><a id="l00578" name="l00578"></a><span class="lineno">  578</span><span class="comment">   * ### Rationale ###</span></div>
<div class="line"><a id="l00579" name="l00579"></a><span class="lineno">  579</span><span class="comment">   * Provided due to ubuiquity of code that uses `boost::function::empty()` which `std::function` lacks.</span></div>
<div class="line"><a id="l00580" name="l00580"></a><span class="lineno">  580</span><span class="comment">   *</span></div>
<div class="line"><a id="l00581" name="l00581"></a><span class="lineno">  581</span><span class="comment">   * @return See above.</span></div>
<div class="line"><a id="l00582" name="l00582"></a><span class="lineno">  582</span><span class="comment">   */</span></div>
<div class="line"><a id="l00583" name="l00583"></a><span class="lineno">  583</span>  <span class="keywordtype">bool</span> empty() const noexcept;</div>
<div class="line"><a id="l00584" name="l00584"></a><span class="lineno">  584</span><span class="comment"></span> </div>
<div class="line"><a id="l00585" name="l00585"></a><span class="lineno">  585</span><span class="comment">  /**</span></div>
<div class="line"><a id="l00586" name="l00586"></a><span class="lineno">  586</span><span class="comment">   * Makes `*this` lack any target; i.e., makes it equal to a default-constructed object of this type, so that</span></div>
<div class="line"><a id="l00587" name="l00587"></a><span class="lineno">  587</span><span class="comment">   * `empty() == true` is a post-condition.</span></div>
<div class="line"><a id="l00588" name="l00588"></a><span class="lineno">  588</span><span class="comment">   *</span></div>
<div class="line"><a id="l00589" name="l00589"></a><span class="lineno">  589</span><span class="comment">   * ### Rationale ###</span></div>
<div class="line"><a id="l00590" name="l00590"></a><span class="lineno">  590</span><span class="comment">   * Provided due to ubuiquity of code that uses `boost::function::clear()` which `std::function` lacks.</span></div>
<div class="line"><a id="l00591" name="l00591"></a><span class="lineno">  591</span><span class="comment">   */</span></div>
<div class="line"><a id="l00592" name="l00592"></a><span class="lineno">  592</span>  <span class="keywordtype">void</span> clear() noexcept;</div>
<div class="line"><a id="l00593" name="l00593"></a><span class="lineno">  593</span>}; <span class="comment">// class Function&lt;Result (Args...)&gt;</span></div>
<div class="line"><a id="l00594" name="l00594"></a><span class="lineno">  594</span> </div>
<div class="line"><a id="l00595" name="l00595"></a><span class="lineno">  595</span><span class="preprocessor">#ifdef FLOW_DOXYGEN_ONLY </span><span class="comment">// Actual compilation will ignore the below; but Doxygen will scan it and generate docs.</span></div>
<div class="line"><a id="l00596" name="l00596"></a><span class="lineno">  596</span><span class="comment"></span> </div>
<div class="line"><a id="l00597" name="l00597"></a><span class="lineno">  597</span><span class="comment">/**</span></div>
<div class="line"><a id="l00598" name="l00598"></a><span class="lineno">  598</span><span class="comment"> * The flow::log::Component payload enumeration comprising various log components used by Flow&#39;s own internal logging.</span></div>
<div class="line"><a id="l00599" name="l00599"></a><span class="lineno">  599</span><span class="comment"> * Internal Flow code specifies members thereof when indicating the log component for each particular piece of</span></div>
<div class="line"><a id="l00600" name="l00600"></a><span class="lineno">  600</span><span class="comment"> * logging code.  Flow user specifies it, albeit very rarely, when configuring their program&#39;s logging</span></div>
<div class="line"><a id="l00601" name="l00601"></a><span class="lineno">  601</span><span class="comment"> * such as via flow::log::Config::init_component_to_union_idx_mapping() and flow::log::Config::init_component_names().</span></div>
<div class="line"><a id="l00602" name="l00602"></a><span class="lineno">  602</span><span class="comment"> *</span></div>
<div class="line"><a id="l00603" name="l00603"></a><span class="lineno">  603</span><span class="comment"> * If you are reading this in Doxygen-generated output (likely a web page), be aware that the individual</span></div>
<div class="line"><a id="l00604" name="l00604"></a><span class="lineno">  604</span><span class="comment"> * `enum` values are not documented right here, because flow::log auto-generates those via certain macro</span></div>
<div class="line"><a id="l00605" name="l00605"></a><span class="lineno">  605</span><span class="comment"> * magic, and Doxygen cannot understand what is happening.  However, you will find the same information</span></div>
<div class="line"><a id="l00606" name="l00606"></a><span class="lineno">  606</span><span class="comment"> * directly in the source file `log_component_enum_declare.macros.hpp` (if the latter is clickable, click to see</span></div>
<div class="line"><a id="l00607" name="l00607"></a><span class="lineno">  607</span><span class="comment"> * the source).</span></div>
<div class="line"><a id="l00608" name="l00608"></a><span class="lineno">  608</span><span class="comment"> *</span></div>
<div class="line"><a id="l00609" name="l00609"></a><span class="lineno">  609</span><span class="comment"> * ### Details regarding overall log system init in user program ###</span></div>
<div class="line"><a id="l00610" name="l00610"></a><span class="lineno">  610</span><span class="comment"> *</span></div>
<div class="line"><a id="l00611" name="l00611"></a><span class="lineno">  611</span><span class="comment"> * The following is a less formal reiteration of flow::log::Config documentation and is presented here -- even</span></div>
<div class="line"><a id="l00612" name="l00612"></a><span class="lineno">  612</span><span class="comment"> * though technically in the present context Flow itself is nothing more than yet another module that uses</span></div>
<div class="line"><a id="l00613" name="l00613"></a><span class="lineno">  613</span><span class="comment"> * flow::log for its own logging -- for your convenience.  Flow&#39;s own logging can be seen as the canonical/model</span></div>
<div class="line"><a id="l00614" name="l00614"></a><span class="lineno">  614</span><span class="comment"> * use of flow::log, so other flow::log users can read this to learn the basics of how to configure loggingg.</span></div>
<div class="line"><a id="l00615" name="l00615"></a><span class="lineno">  615</span><span class="comment"> * That&#39;s why we re-explain this info here, in brief form:</span></div>
<div class="line"><a id="l00616" name="l00616"></a><span class="lineno">  616</span><span class="comment"> *</span></div>
<div class="line"><a id="l00617" name="l00617"></a><span class="lineno">  617</span><span class="comment"> * Your program -- that uses the present library -- can register this `enum` in order for these components</span></div>
<div class="line"><a id="l00618" name="l00618"></a><span class="lineno">  618</span><span class="comment"> * (and particularly the log messages that specify them via flow::log::Log_context or</span></div>
<div class="line"><a id="l00619" name="l00619"></a><span class="lineno">  619</span><span class="comment"> * FLOW_LOG_SET_CONTEXT()) to be logged properly in that program, co-existing correctly with other code bases</span></div>
<div class="line"><a id="l00620" name="l00620"></a><span class="lineno">  620</span><span class="comment"> * that use flow::log for logging.  Typically one constructs a `flow::log::Config C` and then at some point</span></div>
<div class="line"><a id="l00621" name="l00621"></a><span class="lineno">  621</span><span class="comment"> * before logging begins:</span></div>
<div class="line"><a id="l00622" name="l00622"></a><span class="lineno">  622</span><span class="comment"> *   - For each `enum class X_log_component` (note that `Flow_log_component` is only one such `enum class`):</span></div>
<div class="line"><a id="l00623" name="l00623"></a><span class="lineno">  623</span><span class="comment"> *     -# `C.init_component_to_union_idx_mapping&lt;X_log_component&gt;(K)`, where `K` is a distinct numeric offset,</span></div>
<div class="line"><a id="l00624" name="l00624"></a><span class="lineno">  624</span><span class="comment"> *         maybe multiple of 1000.</span></div>
<div class="line"><a id="l00625" name="l00625"></a><span class="lineno">  625</span><span class="comment"> *     -# `C.init_component_names&lt;X_log_component&gt;(S_X_LOG_COMPONENT_NAME_MAP, ..., &quot;X-&quot;)`.</span></div>
<div class="line"><a id="l00626" name="l00626"></a><span class="lineno">  626</span><span class="comment"> *        - Note the &quot;X-&quot; prefix, allowing one to prepend a namespace-like string prefix to avoid any output and config</span></div>
<div class="line"><a id="l00627" name="l00627"></a><span class="lineno">  627</span><span class="comment"> *          clashing.</span></div>
<div class="line"><a id="l00628" name="l00628"></a><span class="lineno">  628</span><span class="comment"> *     -# `C.configure_default_verbosity(Sev::S)`, where `S` is some default max severity.</span></div>
<div class="line"><a id="l00629" name="l00629"></a><span class="lineno">  629</span><span class="comment"> *     -# For each component `M` for which one desires a different max severity `S`:</span></div>
<div class="line"><a id="l00630" name="l00630"></a><span class="lineno">  630</span><span class="comment"> *        - `C.configure_component_verbosity&lt;X_log_component&gt;(Sev::S, X_log_component::M)`. OR:</span></div>
<div class="line"><a id="l00631" name="l00631"></a><span class="lineno">  631</span><span class="comment"> *        - `C.configure_component_verbosity_by_name(Sev::S, &quot;X-M&quot;)`.</span></div>
<div class="line"><a id="l00632" name="l00632"></a><span class="lineno">  632</span><span class="comment"> *   - Apply `C` to the flow::log::Logger or `Logger`s you want to affect.</span></div>
<div class="line"><a id="l00633" name="l00633"></a><span class="lineno">  633</span><span class="comment"> *   - Pass the `Logger` or `Logger`s to appropriate APIs that want to log.</span></div>
<div class="line"><a id="l00634" name="l00634"></a><span class="lineno">  634</span><span class="comment"> *</span></div>
<div class="line"><a id="l00635" name="l00635"></a><span class="lineno">  635</span><span class="comment"> * One could make changes after logging has begun, but that&#39;s a separate topic.</span></div>
<div class="line"><a id="l00636" name="l00636"></a><span class="lineno">  636</span><span class="comment"> */</span></div>
<div class="line"><a id="l00637" name="l00637"></a><span class="lineno"><a class="line" href="namespaceflow.html#a3938730ab4b89daf13d027a5f620e7ce">  637</a></span><span class="keyword">enum class</span> <a class="code hl_enumeration" href="namespaceflow.html#a3938730ab4b89daf13d027a5f620e7ce">Flow_log_component</a></div>
<div class="line"><a id="l00638" name="l00638"></a><span class="lineno">  638</span>{<span class="comment"></span></div>
<div class="line"><a id="l00639" name="l00639"></a><span class="lineno">  639</span><span class="comment">  /**</span></div>
<div class="line"><a id="l00640" name="l00640"></a><span class="lineno">  640</span><span class="comment">   * CAUTION -- see flow::Flow_log_component doc header for directions to find actual members of this</span></div>
<div class="line"><a id="l00641" name="l00641"></a><span class="lineno">  641</span><span class="comment">   * `enum class`.  This entry is a placeholder for Doxygen purposes only, because of the macro magic involved</span></div>
<div class="line"><a id="l00642" name="l00642"></a><span class="lineno">  642</span><span class="comment">   * in generating the actual `enum class`.</span></div>
<div class="line"><a id="l00643" name="l00643"></a><span class="lineno">  643</span><span class="comment">   */</span></div>
<div class="line"><a id="l00644" name="l00644"></a><span class="lineno">  644</span>  <a class="code hl_enumvalue" href="namespaceflow.html#a3938730ab4b89daf13d027a5f620e7cea6fba12db09e5bebfaa04f6372c41c2cf">S_END_SENTINEL</a></div>
<div class="line"><a id="l00645" name="l00645"></a><span class="lineno">  645</span>};</div>
<div class="line"><a id="l00646" name="l00646"></a><span class="lineno">  646</span><span class="comment"></span> </div>
<div class="line"><a id="l00647" name="l00647"></a><span class="lineno">  647</span><span class="comment">/**</span></div>
<div class="line"><a id="l00648" name="l00648"></a><span class="lineno">  648</span><span class="comment"> * The map generated by flow::log macro magic that maps each enumerated value in flow::Flow_log_component to its</span></div>
<div class="line"><a id="l00649" name="l00649"></a><span class="lineno">  649</span><span class="comment"> * string representation as used in log output and verbosity config.  Flow user specifies, albeit very rarely,</span></div>
<div class="line"><a id="l00650" name="l00650"></a><span class="lineno">  650</span><span class="comment"> * when configuring their program&#39;s logging via flow::log::Config::init_component_names().</span></div>
<div class="line"><a id="l00651" name="l00651"></a><span class="lineno">  651</span><span class="comment"> *</span></div>
<div class="line"><a id="l00652" name="l00652"></a><span class="lineno">  652</span><span class="comment"> * As a Flow user, you can informally assume that if the component `enum` member is called `S_SOME_NAME`, then</span></div>
<div class="line"><a id="l00653" name="l00653"></a><span class="lineno">  653</span><span class="comment"> * its string counterpart in this map will be auto-computed to be `&quot;SOME_NAME&quot;` (optionally prepended with a</span></div>
<div class="line"><a id="l00654" name="l00654"></a><span class="lineno">  654</span><span class="comment"> * prefix as supplied to flow::log::Config::init_component_names()).  This is achieved via flow::log macro magic.</span></div>
<div class="line"><a id="l00655" name="l00655"></a><span class="lineno">  655</span><span class="comment"> *</span></div>
<div class="line"><a id="l00656" name="l00656"></a><span class="lineno">  656</span><span class="comment"> * @see flow::Flow_log_component first.</span></div>
<div class="line"><a id="l00657" name="l00657"></a><span class="lineno">  657</span><span class="comment"> */</span></div>
<div class="line"><a id="l00658" name="l00658"></a><span class="lineno">  658</span><span class="keyword">extern</span> <span class="keyword">const</span> boost::unordered_multimap&lt;Flow_log_component, std::string&gt; <a class="code hl_variable" href="namespaceflow.html#abef6a1249edc3dd6c7f650235a84bfe4">S_FLOW_LOG_COMPONENT_NAME_MAP</a>;</div>
<div class="line"><a id="l00659" name="l00659"></a><span class="lineno">  659</span> </div>
<div class="line"><a id="l00660" name="l00660"></a><span class="lineno">  660</span><span class="preprocessor">#endif </span><span class="comment">// FLOW_DOXYGEN_ONLY</span></div>
<div class="line"><a id="l00661" name="l00661"></a><span class="lineno">  661</span> </div>
<div class="line"><a id="l00662" name="l00662"></a><span class="lineno">  662</span><span class="comment">// Template implementations.</span></div>
<div class="line"><a id="l00663" name="l00663"></a><span class="lineno">  663</span> </div>
<div class="line"><a id="l00664" name="l00664"></a><span class="lineno">  664</span><span class="keyword">template</span>&lt;<span class="keyword">typename</span> Result, <span class="keyword">typename</span>... Args&gt;</div>
<div class="line"><a id="l00665" name="l00665"></a><span class="lineno"><a class="line" href="classflow_1_1Function_3_01Result_07Args_8_8_8_08_4.html#a2d28043c36fcccd7d888b7f602678f7e">  665</a></span><span class="keywordtype">bool</span> <a class="code hl_class" href="classflow_1_1Function.html">Function</a>&lt;Result (Args...)&gt;::empty() const noexcept</div>
<div class="line"><a id="l00666" name="l00666"></a><span class="lineno">  666</span>{</div>
<div class="line"><a id="l00667" name="l00667"></a><span class="lineno">  667</span>  <span class="keywordflow">return</span> !*<span class="keyword">this</span>;</div>
<div class="line"><a id="l00668" name="l00668"></a><span class="lineno">  668</span>}</div>
<div class="line"><a id="l00669" name="l00669"></a><span class="lineno">  669</span> </div>
<div class="line"><a id="l00670" name="l00670"></a><span class="lineno">  670</span><span class="keyword">template</span>&lt;<span class="keyword">typename</span> Result, <span class="keyword">typename</span>... Args&gt;</div>
<div class="line"><a id="l00671" name="l00671"></a><span class="lineno"><a class="line" href="classflow_1_1Function_3_01Result_07Args_8_8_8_08_4.html#a1965db8003904aaea686c284b2274057">  671</a></span><span class="keywordtype">void</span> <a class="code hl_class" href="classflow_1_1Function.html">Function</a>&lt;Result (Args...)&gt;::clear() noexcept</div>
<div class="line"><a id="l00672" name="l00672"></a><span class="lineno">  672</span>{</div>
<div class="line"><a id="l00673" name="l00673"></a><span class="lineno">  673</span>  *<span class="keyword">this</span> = {};</div>
<div class="line"><a id="l00674" name="l00674"></a><span class="lineno">  674</span>}</div>
<div class="line"><a id="l00675" name="l00675"></a><span class="lineno">  675</span> </div>
<div class="line"><a id="l00676" name="l00676"></a><span class="lineno">  676</span>} <span class="comment">// namespace flow</span></div>
<div class="ttc" id="aclassflow_1_1Function_3_01Result_07Args_8_8_8_08_4_html_ac9d820d29d397987a6a97469f39e367e"><div class="ttname"><a href="classflow_1_1Function_3_01Result_07Args_8_8_8_08_4.html#ac9d820d29d397987a6a97469f39e367e">flow::Function&lt; Result(Args...)&gt;::Function_base</a></div><div class="ttdeci">std::function&lt; Result(Args...)&gt; Function_base</div><div class="ttdoc">Short-hand for the base. We add no data of our own in this subclass, just a handful of APIs.</div><div class="ttdef"><b>Definition:</b> <a href="common_8hpp_source.html#l00566">common.hpp:566</a></div></div>
<div class="ttc" id="aclassflow_1_1Function_html"><div class="ttname"><a href="classflow_1_1Function.html">flow::Function</a></div><div class="ttdef"><b>Definition:</b> <a href="common_8hpp_source.html#l00512">common.hpp:512</a></div></div>
<div class="ttc" id="adetail_2common_8hpp_html"><div class="ttname"><a href="detail_2common_8hpp.html">common.hpp</a></div></div>
<div class="ttc" id="anamespaceflow_html"><div class="ttname"><a href="namespaceflow.html">flow</a></div><div class="ttdoc">Catch-all namespace for the Flow project: A collection of various production-quality modules written ...</div><div class="ttdef"><b>Definition:</b> <a href="async__fwd_8hpp_source.html#l00074">async_fwd.hpp:75</a></div></div>
<div class="ttc" id="anamespaceflow_html_a29eaaa9d0fac4ce87d8b969222dbed09"><div class="ttname"><a href="namespaceflow.html#a29eaaa9d0fac4ce87d8b969222dbed09">flow::Error_code</a></div><div class="ttdeci">boost::system::error_code Error_code</div><div class="ttdoc">Short-hand for a boost.system error code (which basically encapsulates an integer/enum error code and...</div><div class="ttdef"><b>Definition:</b> <a href="common_8hpp_source.html#l00508">common.hpp:508</a></div></div>
<div class="ttc" id="anamespaceflow_html_a3938730ab4b89daf13d027a5f620e7ce"><div class="ttname"><a href="namespaceflow.html#a3938730ab4b89daf13d027a5f620e7ce">flow::Flow_log_component</a></div><div class="ttdeci">Flow_log_component</div><div class="ttdoc">The flow::log::Component payload enumeration comprising various log components used by Flow's own int...</div><div class="ttdef"><b>Definition:</b> <a href="common_8hpp_source.html#l00637">common.hpp:638</a></div></div>
<div class="ttc" id="anamespaceflow_html_a3938730ab4b89daf13d027a5f620e7cea6fba12db09e5bebfaa04f6372c41c2cf"><div class="ttname"><a href="namespaceflow.html#a3938730ab4b89daf13d027a5f620e7cea6fba12db09e5bebfaa04f6372c41c2cf">flow::Flow_log_component::S_END_SENTINEL</a></div><div class="ttdeci">@ S_END_SENTINEL</div><div class="ttdoc">CAUTION – see flow::Flow_log_component doc header for directions to find actual members of this enum ...</div></div>
<div class="ttc" id="anamespaceflow_html_a48799f1263cdeedec125be51a3db2b79"><div class="ttname"><a href="namespaceflow.html#a48799f1263cdeedec125be51a3db2b79">flow::Fine_duration</a></div><div class="ttdeci">Fine_clock::duration Fine_duration</div><div class="ttdoc">A high-res time duration as computed from two Fine_time_pts.</div><div class="ttdef"><b>Definition:</b> <a href="common_8hpp_source.html#l00416">common.hpp:416</a></div></div>
<div class="ttc" id="anamespaceflow_html_a8f2e48761f9ca3ffcaa29872078bbf00"><div class="ttname"><a href="namespaceflow.html#a8f2e48761f9ca3ffcaa29872078bbf00">flow::Fine_clock</a></div><div class="ttdeci">boost::chrono::high_resolution_clock Fine_clock</div><div class="ttdoc">Clock used for delicate time measurements, such that the now() method gets the current time relative ...</div><div class="ttdef"><b>Definition:</b> <a href="common_8hpp_source.html#l00410">common.hpp:410</a></div></div>
<div class="ttc" id="anamespaceflow_html_a96b8a241b21c907e96cb91f4bf868446"><div class="ttname"><a href="namespaceflow.html#a96b8a241b21c907e96cb91f4bf868446">flow::int8_t</a></div><div class="ttdeci">signed char int8_t</div><div class="ttdoc">Signed byte. Prefer to use uint8_t when representing binary data. This is 8 bits on all modern system...</div><div class="ttdef"><b>Definition:</b> <a href="common_8hpp_source.html#l00393">common.hpp:393</a></div></div>
<div class="ttc" id="anamespaceflow_html_a9d9cc2eeb10d398cff5591d446b763b8"><div class="ttname"><a href="namespaceflow.html#a9d9cc2eeb10d398cff5591d446b763b8">flow::Fine_time_pt</a></div><div class="ttdeci">Fine_clock::time_point Fine_time_pt</div><div class="ttdoc">A high-res time point as returned by Fine_clock::now() and suitable for precise time math in general.</div><div class="ttdef"><b>Definition:</b> <a href="common_8hpp_source.html#l00413">common.hpp:413</a></div></div>
<div class="ttc" id="anamespaceflow_html_abef6a1249edc3dd6c7f650235a84bfe4"><div class="ttname"><a href="namespaceflow.html#abef6a1249edc3dd6c7f650235a84bfe4">flow::S_FLOW_LOG_COMPONENT_NAME_MAP</a></div><div class="ttdeci">const boost::unordered_multimap&lt; Flow_log_component, std::string &gt; S_FLOW_LOG_COMPONENT_NAME_MAP</div><div class="ttdoc">The map generated by flow::log macro magic that maps each enumerated value in flow::Flow_log_componen...</div></div>
<div class="ttc" id="anamespaceflow_html_ae02da22c4a101eaab447511c905e4f32"><div class="ttname"><a href="namespaceflow.html#ae02da22c4a101eaab447511c905e4f32">flow::uint8_t</a></div><div class="ttdeci">unsigned char uint8_t</div><div class="ttdoc">Byte. Best way to represent a byte of binary data. This is 8 bits on all modern systems.</div><div class="ttdef"><b>Definition:</b> <a href="common_8hpp_source.html#l00391">common.hpp:391</a></div></div>
</div><!-- fragment --></div><!-- contents -->
<!-- start footer part -->
<hr class="footer"/><address class="footer"><small>
Generated on Fri Mar 28 2025 22:55:35 for Flow by&#160;<a href="https://www.doxygen.org/index.html"><img class="footer" src="doxygen.svg" width="104" height="31" alt="doxygen"/></a> 1.9.4
</small></address>
</body>
</html>
